linux-stable.git/fs/inode.c, branch linux-2.6.33.y

mm: prevent concurrent unmap_mapping_range() on the same inode

2011-07-13T03:31:27+00:00

commit 2aa15890f3c191326678f1bd68af61ec6b8753ec upstream.

Michael Leun reported that running parallel opens on a fuse filesystem
can trigger a "kernel BUG at mm/truncate.c:475"

Gurudas Pai reported the same bug on NFS.

The reason is, unmap_mapping_range() is not prepared for more than
one concurrent invocation per inode.  For example:

  thread1: going through a big range, stops in the middle of a vma and
     stores the restart address in vm_truncate_count.

  thread2: comes in with a small (e.g. single page) unmap request on
     the same vma, somewhere before restart_address, finds that the
     vma was already unmapped up to the restart address and happily
     returns without doing anything.

Another scenario would be two big unmap requests, both having to
restart the unmapping and each one setting vm_truncate_count to its
own value.  This could go on forever without any of them being able to
finish.

Truncate and hole punching already serialize with i_mutex.  Other
callers of unmap_mapping_range() do not, and it's difficult to get
i_mutex protection for all callers.  In particular ->d_revalidate(),
which calls invalidate_inode_pages2_range() in fuse, may be called
with or without i_mutex.

This patch adds a new mutex to 'struct address_space' to prevent
running multiple concurrent unmap_mapping_range() on the same mapping.

[ We'll hopefully get rid of all this with the upcoming mm
  preemptibility series by Peter Zijlstra, the "mm: Remove i_mmap_mutex
  lockbreak" patch in particular.  But that is for 2.6.39 ]

Signed-off-by: Miklos Szeredi 
Reported-by: Michael Leun 
Reported-by: Gurudas Pai 
Tested-by: Gurudas Pai 
Acked-by: Hugh Dickins 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

kill I_LOCK

2009-12-17T16:03:25+00:00

After I_SYNC was split from I_LOCK the leftover is always used together with
I_NEW and thus superflous.

Signed-off-by: Christoph Hellwig 
Signed-off-by: Al Viro

LSM: imbed ima calls in the security hooks

2009-10-25T04:22:48+00:00

Based on discussions on LKML and LSM, where there are consecutive
security_ and ima_ calls in the vfs layer, move the ima_ calls to
the existing security_ hooks.

Signed-off-by: Mimi Zohar 
Signed-off-by: James Morris

vfs: optimize touch_time() too

2009-09-24T11:47:27+00:00

Do a similar optimization as earlier for touch_atime.  Getting the lock in
mnt_get_write is relatively costly, so try all avenues to avoid it first.

This patch is careful to still only update inode fields inside the lock
region.

This didn't show up in benchmarks, but it's easy enough to do.

[akpm@linux-foundation.org: fix typo in comment]
[hugh.dickins@tiscali.co.uk: fix inverted test of mnt_want_write_file()]
Signed-off-by: Andi Kleen 
Cc: Christoph Hellwig 
Cc: Valerie Aurora 
Cc: Al Viro 
Cc: Dave Hansen 
Signed-off-by: Hugh Dickins 
Signed-off-by: Andrew Morton 
Signed-off-by: Al Viro

vfs: optimization for touch_atime()

2009-09-24T11:47:26+00:00

Some benchmark testing shows touch_atime to be high up in profile logs for
IO intensive workloads.  Most likely that's due to the lock in
mnt_want_write().  Unfortunately touch_atime first takes the lock, and
then does all the other tests that could avoid atime updates (like noatime
or relatime).

Do it the other way round -- first try to avoid the update and only then
if that didn't succeed take the lock.  That works because none of the
atime avoidance tests rely on locking.

This also eliminates a goto.

Signed-off-by: Andi Kleen 
Cc: Christoph Hellwig 
Reviewed-by: Valerie Aurora 
Cc: Al Viro 
Cc: Dave Hansen 
Signed-off-by: Andrew Morton 
Signed-off-by: Al Viro

vfs: split generic_forget_inode() so that hugetlbfs does not have to copy it

2009-09-24T11:47:25+00:00

Hugetlbfs needs to do special things instead of truncate_inode_pages().
 Currently, it copied generic_forget_inode() except for
truncate_inode_pages() call which is asking for trouble (the code there
isn't trivial).  So create a separate function generic_detach_inode()
which does all the list magic done in generic_forget_inode() and call
it from hugetlbfs_forget_inode().

Signed-off-by: Jan Kara 
Cc: Al Viro 
Cc: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Signed-off-by: Al Viro

fs/inode.c: add dev-id and inode number for debugging in init_special_inode()

2009-09-24T11:47:24+00:00

Add device-id and inode number for better debugging.  This was suggested
by Andreas in one of the threads
http://article.gmane.org/gmane.comp.file-systems.ext4/12062 .

"If anyone has a chance, fixing this error message to be not-useless would
be good...  Including the device name and the inode number would help
track down the source of the problem."

Signed-off-by: Manish Katiyar 
Cc: Andreas Dilger 
Cc: Al Viro 
Signed-off-by: Andrew Morton 
Signed-off-by: Al Viro

fs: turn iprune_mutex into rwsem

2009-09-23T14:39:29+00:00

We have had a report of bad memory allocation latency during DVD-RAM (UDF)
writing.  This is causing the user's desktop session to become unusable.

Jan tracked the cause of this down to UDF inode reclaim blocking:

gnome-screens D ffff810006d1d598     0 20686      1
 ffff810006d1d508 0000000000000082 ffff810037db6718 0000000000000800
 ffff810006d1d488 ffffffff807e4280 ffffffff807e4280 ffff810006d1a580
 ffff8100bccbc140 ffff810006d1a8c0 0000000006d1d4e8 ffff810006d1a8c0
Call Trace:
 [] io_schedule+0x63/0xa5
 [] sync_buffer+0x3b/0x3f
 [] __wait_on_bit+0x47/0x79
 [] out_of_line_wait_on_bit+0x6a/0x77
 [] __wait_on_buffer+0x1f/0x21
 [] __bread+0x70/0x86
 [] :udf:udf_tread+0x38/0x3a
 [] :udf:udf_update_inode+0x4d/0x68c
 [] :udf:udf_write_inode+0x1d/0x2b
 [] __writeback_single_inode+0x1c0/0x394
 [] write_inode_now+0x7d/0xc4
 [] :udf:udf_clear_inode+0x3d/0x53
 [] clear_inode+0xc2/0x11b
 [] dispose_list+0x5b/0x102
 [] shrink_icache_memory+0x1dd/0x213
 [] shrink_slab+0xe3/0x158
 [] try_to_free_pages+0x177/0x232
 [] __alloc_pages+0x1fa/0x392
 [] alloc_page_vma+0x176/0x189
 [] __do_fault+0x10c/0x417
 [] handle_mm_fault+0x466/0x940
 [] do_page_fault+0x676/0xabf

This blocks with iprune_mutex held, which then blocks other reclaimers:

X             D ffff81009d47c400     0 17285  14831
 ffff8100844f3728 0000000000000086 0000000000000000 ffff81000000e288
 ffff81000000da00 ffffffff807e4280 ffffffff807e4280 ffff81009d47c400
 ffffffff805ff890 ffff81009d47c740 00000000844f3808 ffff81009d47c740
Call Trace:
 [] __mutex_lock_slowpath+0x72/0xa9
 [] mutex_lock+0x1e/0x22
 [] shrink_icache_memory+0x49/0x213
 [] shrink_slab+0xe3/0x158
 [] try_to_free_pages+0x177/0x232
 [] __alloc_pages+0x1fa/0x392
 [] alloc_pages_current+0xd1/0xd6
 [] __get_free_pages+0xe/0x4d
 [] __pollwait+0x5e/0xdf
 [] :nvidia:nv_kern_poll+0x2e/0x73
 [] do_select+0x308/0x506
 [] core_sys_select+0x1a6/0x254
 [] sys_select+0xb5/0x157

Now I think the main problem is having the filesystem block (and do IO) in
inode reclaim.  The problem is that this doesn't get accounted well and
penalizes a random allocator with a big latency spike caused by work
generated from elsewhere.

I think the best idea would be to avoid this.  By design if possible, or
by deferring the hard work to an asynchronous context.  If the latter,
then the fs would probably want to throttle creation of new work with
queue size of the deferred work, but let's not get into those details.

Anyway, the other obvious thing we looked at is the iprune_mutex which is
causing the cascading blocking.  We could turn this into an rwsem to
improve concurrency.  It is unreasonable to totally ban all potentially
slow or blocking operations in inode reclaim, so I think this is a cheap
way to get a small improvement.

This doesn't solve the whole problem of course.  The process doing inode
reclaim will still take the latency hit, and concurrent processes may end
up contending on filesystem locks.  So fs developers should keep these
problems in mind.

Signed-off-by: Nick Piggin 
Cc: Jan Kara 
Cc: Al Viro 
Cc: Christoph Hellwig 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

const: mark remaining inode_operations as const

2009-09-22T14:17:24+00:00

Signed-off-by: Alexey Dobriyan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

fs: make sure data stored into inode is properly seen before unlocking new inode

2009-09-22T14:17:24+00:00

In theory it could happen that on one CPU we initialize a new inode but
clearing of I_NEW | I_LOCK gets reordered before some of the
initialization.  Thus on another CPU we return not fully uptodate inode
from iget_locked().

This seems to fix a corruption issue on ext3 mounted over NFS.

[akpm@linux-foundation.org: add some commentary]
Signed-off-by: Jan Kara 
Cc: Christoph Hellwig 
Cc: 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds