<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux.git/fs/afs, branch v2.6.33</title>
<subtitle>Linux kernel source tree</subtitle>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/'/>
<entry>
<title>afs: remove manual O_SYNC handling</title>
<updated>2009-12-10T14:02:50+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2009-09-30T20:16:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=027cf316afff03d310281709314fbc0899984759'/>
<id>027cf316afff03d310281709314fbc0899984759</id>
<content type='text'>
generic_file_aio_write already calls into -&gt;fsync to handle O_SYNC/O_DSYNC.
Remove the duplicate manual invocation.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
generic_file_aio_write already calls into -&gt;fsync to handle O_SYNC/O_DSYNC.
Remove the duplicate manual invocation.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>vfs: Implement proper O_SYNC semantics</title>
<updated>2009-12-10T14:02:50+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2009-10-27T10:05:28+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6b2f3d1f769be5779b479c37800229d9a4809fc3'/>
<id>6b2f3d1f769be5779b479c37800229d9a4809fc3</id>
<content type='text'>
While Linux provided an O_SYNC flag basically since day 1, it took until
Linux 2.4.0-test12pre2 to actually get it implemented for filesystems,
since that day we had generic_osync_around with only minor changes and the
great "For now, when the user asks for O_SYNC, we'll actually give
O_DSYNC" comment.  This patch intends to actually give us real O_SYNC
semantics in addition to the O_DSYNC semantics.  After Jan's O_SYNC
patches which are required before this patch it's actually surprisingly
simple, we just need to figure out when to set the datasync flag to
vfs_fsync_range and when not.

This patch renames the existing O_SYNC flag to O_DSYNC while keeping it's
numerical value to keep binary compatibility, and adds a new real O_SYNC
flag.  To guarantee backwards compatiblity it is defined as expanding to
both the O_DSYNC and the new additional binary flag (__O_SYNC) to make
sure we are backwards-compatible when compiled against the new headers.

This also means that all places that don't care about the differences can
just check O_DSYNC and get the right behaviour for O_SYNC, too - only
places that actuall care need to check __O_SYNC in addition.  Drivers and
network filesystems have been updated in a fail safe way to always do the
full sync magic if O_DSYNC is set.  The few places setting O_SYNC for
lower layers are kept that way for now to stay failsafe.

We enforce that O_DSYNC is set when __O_SYNC is set early in the open path
to make sure we always get these sane options.

Note that parisc really screwed up their headers as they already define a
O_DSYNC that has always been a no-op.  We try to repair it by using it for
the new O_DSYNC and redefinining O_SYNC to send both the traditional
O_SYNC numerical value _and_ the O_DSYNC one.

Cc: Richard Henderson &lt;rth@twiddle.net&gt;
Cc: Ivan Kokshaysky &lt;ink@jurassic.park.msu.ru&gt;
Cc: Grant Grundler &lt;grundler@parisc-linux.org&gt;
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Andreas Dilger &lt;adilger@sun.com&gt;
Acked-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Acked-by: Kyle McMartin &lt;kyle@mcmartin.ca&gt;
Acked-by: Ulrich Drepper &lt;drepper@redhat.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
While Linux provided an O_SYNC flag basically since day 1, it took until
Linux 2.4.0-test12pre2 to actually get it implemented for filesystems,
since that day we had generic_osync_around with only minor changes and the
great "For now, when the user asks for O_SYNC, we'll actually give
O_DSYNC" comment.  This patch intends to actually give us real O_SYNC
semantics in addition to the O_DSYNC semantics.  After Jan's O_SYNC
patches which are required before this patch it's actually surprisingly
simple, we just need to figure out when to set the datasync flag to
vfs_fsync_range and when not.

This patch renames the existing O_SYNC flag to O_DSYNC while keeping it's
numerical value to keep binary compatibility, and adds a new real O_SYNC
flag.  To guarantee backwards compatiblity it is defined as expanding to
both the O_DSYNC and the new additional binary flag (__O_SYNC) to make
sure we are backwards-compatible when compiled against the new headers.

This also means that all places that don't care about the differences can
just check O_DSYNC and get the right behaviour for O_SYNC, too - only
places that actuall care need to check __O_SYNC in addition.  Drivers and
network filesystems have been updated in a fail safe way to always do the
full sync magic if O_DSYNC is set.  The few places setting O_SYNC for
lower layers are kept that way for now to stay failsafe.

We enforce that O_DSYNC is set when __O_SYNC is set early in the open path
to make sure we always get these sane options.

Note that parisc really screwed up their headers as they already define a
O_DSYNC that has always been a no-op.  We try to repair it by using it for
the new O_DSYNC and redefinining O_SYNC to send both the traditional
O_SYNC numerical value _and_ the O_DSYNC one.

Cc: Richard Henderson &lt;rth@twiddle.net&gt;
Cc: Ivan Kokshaysky &lt;ink@jurassic.park.msu.ru&gt;
Cc: Grant Grundler &lt;grundler@parisc-linux.org&gt;
Cc: "David S. Miller" &lt;davem@davemloft.net&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: "H. Peter Anvin" &lt;hpa@zytor.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Cc: Al Viro &lt;viro@zeniv.linux.org.uk&gt;
Cc: Andreas Dilger &lt;adilger@sun.com&gt;
Acked-by: Trond Myklebust &lt;Trond.Myklebust@netapp.com&gt;
Acked-by: Kyle McMartin &lt;kyle@mcmartin.ca&gt;
Acked-by: Ulrich Drepper &lt;drepper@redhat.com&gt;
Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>FS-Cache: Handle pages pending storage that get evicted under OOM conditions</title>
<updated>2009-11-19T18:11:35+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2009-11-19T18:11:35+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=201a15428bd54f83eccec8b7c64a04b8f9431204'/>
<id>201a15428bd54f83eccec8b7c64a04b8f9431204</id>
<content type='text'>
Handle netfs pages that the vmscan algorithm wants to evict from the pagecache
under OOM conditions, but that are waiting for write to the cache.  Under these
conditions, vmscan calls the releasepage() function of the netfs, asking if a
page can be discarded.

The problem is typified by the following trace of a stuck process:

	kslowd005     D 0000000000000000     0  4253      2 0x00000080
	 ffff88001b14f370 0000000000000046 ffff880020d0d000 0000000000000007
	 0000000000000006 0000000000000001 ffff88001b14ffd8 ffff880020d0d2a8
	 000000000000ddf0 00000000000118c0 00000000000118c0 ffff880020d0d2a8
	Call Trace:
	 [&lt;ffffffffa00782d8&gt;] __fscache_wait_on_page_write+0x8b/0xa7 [fscache]
	 [&lt;ffffffff8104c0f1&gt;] ? autoremove_wake_function+0x0/0x34
	 [&lt;ffffffffa0078240&gt;] ? __fscache_check_page_write+0x63/0x70 [fscache]
	 [&lt;ffffffffa00b671d&gt;] nfs_fscache_release_page+0x4e/0xc4 [nfs]
	 [&lt;ffffffffa00927f0&gt;] nfs_release_page+0x3c/0x41 [nfs]
	 [&lt;ffffffff810885d3&gt;] try_to_release_page+0x32/0x3b
	 [&lt;ffffffff81093203&gt;] shrink_page_list+0x316/0x4ac
	 [&lt;ffffffff8109372b&gt;] shrink_inactive_list+0x392/0x67c
	 [&lt;ffffffff813532fa&gt;] ? __mutex_unlock_slowpath+0x100/0x10b
	 [&lt;ffffffff81058df0&gt;] ? trace_hardirqs_on_caller+0x10c/0x130
	 [&lt;ffffffff8135330e&gt;] ? mutex_unlock+0x9/0xb
	 [&lt;ffffffff81093aa2&gt;] shrink_list+0x8d/0x8f
	 [&lt;ffffffff81093d1c&gt;] shrink_zone+0x278/0x33c
	 [&lt;ffffffff81052d6c&gt;] ? ktime_get_ts+0xad/0xba
	 [&lt;ffffffff81094b13&gt;] try_to_free_pages+0x22e/0x392
	 [&lt;ffffffff81091e24&gt;] ? isolate_pages_global+0x0/0x212
	 [&lt;ffffffff8108e743&gt;] __alloc_pages_nodemask+0x3dc/0x5cf
	 [&lt;ffffffff81089529&gt;] grab_cache_page_write_begin+0x65/0xaa
	 [&lt;ffffffff8110f8c0&gt;] ext3_write_begin+0x78/0x1eb
	 [&lt;ffffffff81089ec5&gt;] generic_file_buffered_write+0x109/0x28c
	 [&lt;ffffffff8103cb69&gt;] ? current_fs_time+0x22/0x29
	 [&lt;ffffffff8108a509&gt;] __generic_file_aio_write+0x350/0x385
	 [&lt;ffffffff8108a588&gt;] ? generic_file_aio_write+0x4a/0xae
	 [&lt;ffffffff8108a59e&gt;] generic_file_aio_write+0x60/0xae
	 [&lt;ffffffff810b2e82&gt;] do_sync_write+0xe3/0x120
	 [&lt;ffffffff8104c0f1&gt;] ? autoremove_wake_function+0x0/0x34
	 [&lt;ffffffff810b18e1&gt;] ? __dentry_open+0x1a5/0x2b8
	 [&lt;ffffffff810b1a76&gt;] ? dentry_open+0x82/0x89
	 [&lt;ffffffffa00e693c&gt;] cachefiles_write_page+0x298/0x335 [cachefiles]
	 [&lt;ffffffffa0077147&gt;] fscache_write_op+0x178/0x2c2 [fscache]
	 [&lt;ffffffffa0075656&gt;] fscache_op_execute+0x7a/0xd1 [fscache]
	 [&lt;ffffffff81082093&gt;] slow_work_execute+0x18f/0x2d1
	 [&lt;ffffffff8108239a&gt;] slow_work_thread+0x1c5/0x308
	 [&lt;ffffffff8104c0f1&gt;] ? autoremove_wake_function+0x0/0x34
	 [&lt;ffffffff810821d5&gt;] ? slow_work_thread+0x0/0x308
	 [&lt;ffffffff8104be91&gt;] kthread+0x7a/0x82
	 [&lt;ffffffff8100beda&gt;] child_rip+0xa/0x20
	 [&lt;ffffffff8100b87c&gt;] ? restore_args+0x0/0x30
	 [&lt;ffffffff8102ef83&gt;] ? tg_shares_up+0x171/0x227
	 [&lt;ffffffff8104be17&gt;] ? kthread+0x0/0x82
	 [&lt;ffffffff8100bed0&gt;] ? child_rip+0x0/0x20

In the above backtrace, the following is happening:

 (1) A page storage operation is being executed by a slow-work thread
     (fscache_write_op()).

 (2) FS-Cache farms the operation out to the cache to perform
     (cachefiles_write_page()).

 (3) CacheFiles is then calling Ext3 to perform the actual write, using Ext3's
     standard write (do_sync_write()) under KERNEL_DS directly from the netfs
     page.

 (4) However, for Ext3 to perform the write, it must allocate some memory, in
     particular, it must allocate at least one page cache page into which it
     can copy the data from the netfs page.

 (5) Under OOM conditions, the memory allocator can't immediately come up with
     a page, so it uses vmscan to find something to discard
     (try_to_free_pages()).

 (6) vmscan finds a clean netfs page it might be able to discard (possibly the
     one it's trying to write out).

 (7) The netfs is called to throw the page away (nfs_release_page()) - but it's
     called with __GFP_WAIT, so the netfs decides to wait for the store to
     complete (__fscache_wait_on_page_write()).

 (8) This blocks a slow-work processing thread - possibly against itself.

The system ends up stuck because it can't write out any netfs pages to the
cache without allocating more memory.

To avoid this, we make FS-Cache cancel some writes that aren't in the middle of
actually being performed.  This means that some data won't make it into the
cache this time.  To support this, a new FS-Cache function is added
fscache_maybe_release_page() that replaces what the netfs releasepage()
functions used to do with respect to the cache.

The decisions fscache_maybe_release_page() makes are counted and displayed
through /proc/fs/fscache/stats on a line labelled "VmScan".  There are four
counters provided: "nos=N" - pages that weren't pending storage; "gon=N" -
pages that were pending storage when we first looked, but weren't by the time
we got the object lock; "bsy=N" - pages that we ignored as they were actively
being written when we looked; and "can=N" - pages that we cancelled the storage
of.

What I'd really like to do is alter the behaviour of the cancellation
heuristics, depending on how necessary it is to expel pages.  If there are
plenty of other pages that aren't waiting to be written to the cache that
could be ejected first, then it would be nice to hold up on immediate
cancellation of cache writes - but I don't see a way of doing that.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Handle netfs pages that the vmscan algorithm wants to evict from the pagecache
under OOM conditions, but that are waiting for write to the cache.  Under these
conditions, vmscan calls the releasepage() function of the netfs, asking if a
page can be discarded.

The problem is typified by the following trace of a stuck process:

	kslowd005     D 0000000000000000     0  4253      2 0x00000080
	 ffff88001b14f370 0000000000000046 ffff880020d0d000 0000000000000007
	 0000000000000006 0000000000000001 ffff88001b14ffd8 ffff880020d0d2a8
	 000000000000ddf0 00000000000118c0 00000000000118c0 ffff880020d0d2a8
	Call Trace:
	 [&lt;ffffffffa00782d8&gt;] __fscache_wait_on_page_write+0x8b/0xa7 [fscache]
	 [&lt;ffffffff8104c0f1&gt;] ? autoremove_wake_function+0x0/0x34
	 [&lt;ffffffffa0078240&gt;] ? __fscache_check_page_write+0x63/0x70 [fscache]
	 [&lt;ffffffffa00b671d&gt;] nfs_fscache_release_page+0x4e/0xc4 [nfs]
	 [&lt;ffffffffa00927f0&gt;] nfs_release_page+0x3c/0x41 [nfs]
	 [&lt;ffffffff810885d3&gt;] try_to_release_page+0x32/0x3b
	 [&lt;ffffffff81093203&gt;] shrink_page_list+0x316/0x4ac
	 [&lt;ffffffff8109372b&gt;] shrink_inactive_list+0x392/0x67c
	 [&lt;ffffffff813532fa&gt;] ? __mutex_unlock_slowpath+0x100/0x10b
	 [&lt;ffffffff81058df0&gt;] ? trace_hardirqs_on_caller+0x10c/0x130
	 [&lt;ffffffff8135330e&gt;] ? mutex_unlock+0x9/0xb
	 [&lt;ffffffff81093aa2&gt;] shrink_list+0x8d/0x8f
	 [&lt;ffffffff81093d1c&gt;] shrink_zone+0x278/0x33c
	 [&lt;ffffffff81052d6c&gt;] ? ktime_get_ts+0xad/0xba
	 [&lt;ffffffff81094b13&gt;] try_to_free_pages+0x22e/0x392
	 [&lt;ffffffff81091e24&gt;] ? isolate_pages_global+0x0/0x212
	 [&lt;ffffffff8108e743&gt;] __alloc_pages_nodemask+0x3dc/0x5cf
	 [&lt;ffffffff81089529&gt;] grab_cache_page_write_begin+0x65/0xaa
	 [&lt;ffffffff8110f8c0&gt;] ext3_write_begin+0x78/0x1eb
	 [&lt;ffffffff81089ec5&gt;] generic_file_buffered_write+0x109/0x28c
	 [&lt;ffffffff8103cb69&gt;] ? current_fs_time+0x22/0x29
	 [&lt;ffffffff8108a509&gt;] __generic_file_aio_write+0x350/0x385
	 [&lt;ffffffff8108a588&gt;] ? generic_file_aio_write+0x4a/0xae
	 [&lt;ffffffff8108a59e&gt;] generic_file_aio_write+0x60/0xae
	 [&lt;ffffffff810b2e82&gt;] do_sync_write+0xe3/0x120
	 [&lt;ffffffff8104c0f1&gt;] ? autoremove_wake_function+0x0/0x34
	 [&lt;ffffffff810b18e1&gt;] ? __dentry_open+0x1a5/0x2b8
	 [&lt;ffffffff810b1a76&gt;] ? dentry_open+0x82/0x89
	 [&lt;ffffffffa00e693c&gt;] cachefiles_write_page+0x298/0x335 [cachefiles]
	 [&lt;ffffffffa0077147&gt;] fscache_write_op+0x178/0x2c2 [fscache]
	 [&lt;ffffffffa0075656&gt;] fscache_op_execute+0x7a/0xd1 [fscache]
	 [&lt;ffffffff81082093&gt;] slow_work_execute+0x18f/0x2d1
	 [&lt;ffffffff8108239a&gt;] slow_work_thread+0x1c5/0x308
	 [&lt;ffffffff8104c0f1&gt;] ? autoremove_wake_function+0x0/0x34
	 [&lt;ffffffff810821d5&gt;] ? slow_work_thread+0x0/0x308
	 [&lt;ffffffff8104be91&gt;] kthread+0x7a/0x82
	 [&lt;ffffffff8100beda&gt;] child_rip+0xa/0x20
	 [&lt;ffffffff8100b87c&gt;] ? restore_args+0x0/0x30
	 [&lt;ffffffff8102ef83&gt;] ? tg_shares_up+0x171/0x227
	 [&lt;ffffffff8104be17&gt;] ? kthread+0x0/0x82
	 [&lt;ffffffff8100bed0&gt;] ? child_rip+0x0/0x20

In the above backtrace, the following is happening:

 (1) A page storage operation is being executed by a slow-work thread
     (fscache_write_op()).

 (2) FS-Cache farms the operation out to the cache to perform
     (cachefiles_write_page()).

 (3) CacheFiles is then calling Ext3 to perform the actual write, using Ext3's
     standard write (do_sync_write()) under KERNEL_DS directly from the netfs
     page.

 (4) However, for Ext3 to perform the write, it must allocate some memory, in
     particular, it must allocate at least one page cache page into which it
     can copy the data from the netfs page.

 (5) Under OOM conditions, the memory allocator can't immediately come up with
     a page, so it uses vmscan to find something to discard
     (try_to_free_pages()).

 (6) vmscan finds a clean netfs page it might be able to discard (possibly the
     one it's trying to write out).

 (7) The netfs is called to throw the page away (nfs_release_page()) - but it's
     called with __GFP_WAIT, so the netfs decides to wait for the store to
     complete (__fscache_wait_on_page_write()).

 (8) This blocks a slow-work processing thread - possibly against itself.

The system ends up stuck because it can't write out any netfs pages to the
cache without allocating more memory.

To avoid this, we make FS-Cache cancel some writes that aren't in the middle of
actually being performed.  This means that some data won't make it into the
cache this time.  To support this, a new FS-Cache function is added
fscache_maybe_release_page() that replaces what the netfs releasepage()
functions used to do with respect to the cache.

The decisions fscache_maybe_release_page() makes are counted and displayed
through /proc/fs/fscache/stats on a line labelled "VmScan".  There are four
counters provided: "nos=N" - pages that weren't pending storage; "gon=N" -
pages that were pending storage when we first looked, but weren't by the time
we got the object lock; "bsy=N" - pages that we ignored as they were actively
being written when we looked; and "can=N" - pages that we cancelled the storage
of.

What I'd really like to do is alter the behaviour of the cancellation
heuristics, depending on how necessary it is to expel pages.  If there are
plenty of other pages that aren't waiting to be written to the cache that
could be ejected first, then it would be nice to hold up on immediate
cancellation of cache writes - but I don't see a way of doing that.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>afs: remove cache.h</title>
<updated>2009-10-01T23:11:16+00:00</updated>
<author>
<name>Christoph Hellwig</name>
<email>hch@lst.de</email>
</author>
<published>2009-10-01T22:44:27+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=80e50be4220e1244fcf6d5f75b997f8586ae1300'/>
<id>80e50be4220e1244fcf6d5f75b997f8586ae1300</id>
<content type='text'>
It's just a wrapper for &lt;linux/fscache.h&gt;, so remove it.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It's just a wrapper for &lt;linux/fscache.h&gt;, so remove it.

Signed-off-by: Christoph Hellwig &lt;hch@lst.de&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>seq_file: constify seq_operations</title>
<updated>2009-09-23T14:39:29+00:00</updated>
<author>
<name>James Morris</name>
<email>jmorris@namei.org</email>
</author>
<published>2009-09-22T23:43:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=88e9d34c727883d7d6f02cf1475b3ec98b8480c7'/>
<id>88e9d34c727883d7d6f02cf1475b3ec98b8480c7</id>
<content type='text'>
Make all seq_operations structs const, to help mitigate against
revectoring user-triggerable function pointers.

This is derived from the grsecurity patch, although generated from scratch
because it's simpler than extracting the changes from there.

Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
Acked-by: Serge Hallyn &lt;serue@us.ibm.com&gt;
Acked-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Make all seq_operations structs const, to help mitigate against
revectoring user-triggerable function pointers.

This is derived from the grsecurity patch, although generated from scratch
because it's simpler than extracting the changes from there.

Signed-off-by: James Morris &lt;jmorris@namei.org&gt;
Acked-by: Serge Hallyn &lt;serue@us.ibm.com&gt;
Acked-by: Casey Schaufler &lt;casey@schaufler-ca.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>const: make file_lock_operations const</title>
<updated>2009-09-22T14:17:25+00:00</updated>
<author>
<name>Alexey Dobriyan</name>
<email>adobriyan@gmail.com</email>
</author>
<published>2009-09-22T00:01:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=6aed62853c72e29f2c97bbac7712cb398e8c9437'/>
<id>6aed62853c72e29f2c97bbac7712cb398e8c9437</id>
<content type='text'>
Signed-off-by: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Signed-off-by: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>writeback: get rid of wbc-&gt;for_writepages</title>
<updated>2009-09-16T13:16:18+00:00</updated>
<author>
<name>Jens Axboe</name>
<email>jens.axboe@oracle.com</email>
</author>
<published>2009-09-15T13:10:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=1fe06ad89255c211fe100d7f690d10b161398df8'/>
<id>1fe06ad89255c211fe100d7f690d10b161398df8</id>
<content type='text'>
It's only set, it's never checked. Kill it.

Acked-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Jens Axboe &lt;jens.axboe@oracle.com&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It's only set, it's never checked. Kill it.

Acked-by: Jan Kara &lt;jack@suse.cz&gt;
Signed-off-by: Jens Axboe &lt;jens.axboe@oracle.com&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>AFS: Stop readlink() on AFS crashing due to NULL 'file' ptr</title>
<updated>2009-08-27T19:22:08+00:00</updated>
<author>
<name>David Howells</name>
<email>dhowells@redhat.com</email>
</author>
<published>2009-08-27T12:09:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=9886e836a6a5dbd273dc55b17e713f0a188d137f'/>
<id>9886e836a6a5dbd273dc55b17e713f0a188d137f</id>
<content type='text'>
kAFS crashes when asked to read a symbolic link because page_getlink()
passes a NULL file pointer to read_mapping_page(), but afs_readpage()
expects a file pointer from which to extract a key.

Modify afs_readpage() to request the appropriate key from the calling
process's keyrings if a file struct is not supplied with one attached.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: Anton Blanchard &lt;anton@samba.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
kAFS crashes when asked to read a symbolic link because page_getlink()
passes a NULL file pointer to read_mapping_page(), but afs_readpage()
expects a file pointer from which to extract a key.

Modify afs_readpage() to request the appropriate key from the calling
process's keyrings if a file struct is not supplied with one attached.

Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Acked-by: Anton Blanchard &lt;anton@samba.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>AFS: Fix compilation warning</title>
<updated>2009-07-12T19:24:07+00:00</updated>
<author>
<name>Artem Bityutskiy</name>
<email>Artem.Bityutskiy@nokia.com</email>
</author>
<published>2009-07-09T09:44:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=dd0d9a46f573b086a67522f819566427dba9c4c7'/>
<id>dd0d9a46f573b086a67522f819566427dba9c4c7</id>
<content type='text'>
Fix the following warning:

  fs/afs/dir.c: In function 'afs_d_revalidate':
  fs/afs/dir.c:567: warning: 'fid.vnode' may be used uninitialized in this function
  fs/afs/dir.c:567: warning: 'fid.unique' may be used uninitialized in this function

by marking the 'fid' variable as an uninitialized_var.  The problem is
that gcc doesn't always manage to work out that fid is always set on the
path through the function that uses it.

Cc: linux-afs@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Artem Bityutskiy &lt;Artem.Bityutskiy@nokia.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Fix the following warning:

  fs/afs/dir.c: In function 'afs_d_revalidate':
  fs/afs/dir.c:567: warning: 'fid.vnode' may be used uninitialized in this function
  fs/afs/dir.c:567: warning: 'fid.unique' may be used uninitialized in this function

by marking the 'fid' variable as an uninitialized_var.  The problem is
that gcc doesn't always manage to work out that fid is always set on the
path through the function that uses it.

Cc: linux-afs@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Artem Bityutskiy &lt;Artem.Bityutskiy@nokia.com&gt;
Signed-off-by: David Howells &lt;dhowells@redhat.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>headers: smp_lock.h redux</title>
<updated>2009-07-12T19:22:34+00:00</updated>
<author>
<name>Alexey Dobriyan</name>
<email>adobriyan@gmail.com</email>
</author>
<published>2009-07-11T18:08:37+00:00</published>
<link rel='alternate' type='text/html' href='https://git.tavy.me/linux.git/commit/?id=405f55712dfe464b3240d7816cc4fe4174831be2'/>
<id>405f55712dfe464b3240d7816cc4fe4174831be2</id>
<content type='text'>
* Remove smp_lock.h from files which don't need it (including some headers!)
* Add smp_lock.h to files which do need it
* Make smp_lock.h include conditional in hardirq.h
  It's needed only for one kernel_locked() usage which is under CONFIG_PREEMPT

  This will make hardirq.h inclusion cheaper for every PREEMPT=n config
  (which includes allmodconfig/allyesconfig, BTW)

Signed-off-by: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
* Remove smp_lock.h from files which don't need it (including some headers!)
* Add smp_lock.h to files which do need it
* Make smp_lock.h include conditional in hardirq.h
  It's needed only for one kernel_locked() usage which is under CONFIG_PREEMPT

  This will make hardirq.h inclusion cheaper for every PREEMPT=n config
  (which includes allmodconfig/allyesconfig, BTW)

Signed-off-by: Alexey Dobriyan &lt;adobriyan@gmail.com&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
