linux-stable.git/fs/nilfs2/btnode.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

nilfs2: eliminate nilfs_btnode_get function

2009-11-20T01:05:50+00:00

This removes the obsolete nilfs_btnode_get() function and makes
nilfs_btree_get_block() directly call nilfs_btnode_submit_block().

This expansion will provide better opportunity for code optimization.

Signed-off-by: Ryusuke Konishi

nilfs2: remove newblk argument from nilfs_btnode_submit_block

2009-11-20T01:05:50+00:00

This removes the obsolete argument from nilfs_btnode_submit_block().
This will complete separating a create function of btree node.

Signed-off-by: Ryusuke Konishi

nilfs2: use nilfs_btnode_create_block function

2009-11-20T01:05:49+00:00

This displaces nilfs_btnode_get() use to create new btree node block
with nilfs_btnode_create_block.

Signed-off-by: Ryusuke Konishi

nilfs2: separate function for creating new btree node block

2009-11-20T01:05:49+00:00

Adds a separate routine for creating a btree node block.  This is a
preparation to reduce the depth of function calls during submitting
btree node buffer.

Signed-off-by: Ryusuke Konishi

nilfs2: add zero-fill for new btree node buffers

2009-11-03T03:32:03+00:00

Adds missing initialization of newly allocated b-tree node buffers.
This avoids garbage data to be mixed in b-tree node blocks.

Signed-off-by: Ryusuke Konishi

nilfs2: fix dirty page accounting leak causing hang at write

2009-11-03T03:31:36+00:00

Bruno Prémont and Dunphy, Bill noticed me that NILFS will certainly
hang on ARM-based targets.

I found this was caused by an underflow of dirty pages counter.  A
b-tree cache routine was marking page dirty without adjusting page
account information.

This fixes the dirty page accounting leak and resolves the hang on
arm-based targets.

Reported-by: Bruno Prémont 
Reported-by: Dunphy, Bill 
Signed-off-by: Ryusuke Konishi 
Tested-by: Bruno Prémont 
Cc: stable

nilfs2: fix missing zero-fill initialization of btree node cache

2009-09-29T11:12:56+00:00

This will fix file system corruption which infrequently happens after
mount.  The problem was reported from users with the title "[NILFS
users] Fail to mount NILFS." (Message-ID:
<200908211918.34720.yuri@itinteg.net>), and so forth.  I've also
experienced the corruption multiple times on kernel 2.6.30 and 2.6.31.

The problem turned out to be caused due to discordance between
mapping->nrpages of a btree node cache and the actual number of pages
hung on the cache; if the mapping->nrpages becomes zero even as it has
pages, truncate_inode_pages() returns without doing anything.  Usually
this is harmless except it may cause page leak, but garbage collection
fairly infrequently sees a stale page remained in the btree node cache
of DAT (i.e. disk address translation file of nilfs), and induces the
corruption.

I identified a missing initialization in btree node caches was the
root cause.  This corrects the bug.

I've tested this for kernel 2.6.30 and 2.6.31.

Reported-by: Yuri Chislov 
Signed-off-by: Ryusuke Konishi 
Cc: stable

const: mark remaining address_space_operations const

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

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

nilfs2: fix preempt count underflow in nilfs_btnode_prepare_change_key

2009-08-31T03:03:06+00:00

This will fix the following preempt count underflow reported from
users with the title "[NILFS users] segctord problem" (Message-ID:
<949415.6494.qm@web58808.mail.re1.yahoo.com> and Message-ID:
):

 WARNING: at kernel/sched.c:4890 sub_preempt_count+0x95/0xa0()
 Hardware name: HP Compaq 6530b (KR980UT#ABC)
 Modules linked in: bridge stp llc bnep rfcomm l2cap xfs exportfs nilfs2 cowloop loop vboxnetadp vboxnetflt vboxdrv btusb bluetooth uvcvideo videodev v4l1_compat v4l2_compat_ioctl32 arc4 snd_hda_codec_analog ecb iwlagn iwlcore rfkill lib80211 mac80211 snd_hda_intel snd_hda_codec ehci_hcd uhci_hcd usbcore snd_hwdep snd_pcm tg3 cfg80211 psmouse snd_timer joydev libphy ohci1394 snd_page_alloc hp_accel lis3lv02d ieee1394 led_class i915 drm i2c_algo_bit video backlight output i2c_core dm_crypt dm_mod
 Pid: 4197, comm: segctord Not tainted 2.6.30-gentoo-r4-64 #7
 Call Trace:
  [] ? sub_preempt_count+0x95/0xa0
  [] warn_slowpath_common+0x78/0xd0
  [] warn_slowpath_null+0xf/0x20
  [] sub_preempt_count+0x95/0xa0
  [] nilfs_btnode_prepare_change_key+0x11b/0x190 [nilfs2]
  [] nilfs_btree_assign_p+0x19d/0x1e0 [nilfs2]
  [] nilfs_btree_assign+0xbd/0x130 [nilfs2]
  [] nilfs_bmap_assign+0x47/0x70 [nilfs2]
  [] nilfs_segctor_do_construct+0x956/0x20f0 [nilfs2]
  [] ? _spin_unlock_irqrestore+0x12/0x40
  [] ? __up_write+0xe0/0x150
  [] ? up_write+0x9/0x10
  [] ? nilfs_bmap_test_and_clear_dirty+0x43/0x60 [nilfs2]
  [] ? nilfs_mdt_fetch_dirty+0x27/0x60 [nilfs2]
  [] nilfs_segctor_construct+0x8c/0xd0 [nilfs2]
  [] nilfs_segctor_thread+0x15c/0x3a0 [nilfs2]
  [] ? nilfs_construction_timeout+0x0/0x10 [nilfs2]
  [] ? add_timer+0x13/0x20
  [] ? __wake_up_common+0x5a/0x90
  [] ? autoremove_wake_function+0x0/0x40
  [] ? nilfs_segctor_thread+0x0/0x3a0 [nilfs2]
  [] ? nilfs_segctor_thread+0x0/0x3a0 [nilfs2]
  [] kthread+0x56/0x90
  [] child_rip+0xa/0x20
  [] ? kthread+0x0/0x90
  [] ? child_rip+0x0/0x20

This problem was caused due to a missing radix_tree_preload() call in
the retry path of nilfs_btnode_prepare_change_key() function.

Reported-by: Eric A 
Reported-by: Jerome Poulin 
Signed-off-by: Ryusuke Konishi 
Tested-by: Jerome Poulin 
Cc: stable@kernel.org