1. 20 11月, 2009 9 次提交
  2. 15 11月, 2009 1 次提交
  3. 13 11月, 2009 1 次提交
    • R
      nilfs2: fix lock order reversal in chcp operation · c1ea985c
      Ryusuke Konishi 提交于
      Will fix the following lock order reversal lockdep detected:
      
      =======================================================
      [ INFO: possible circular locking dependency detected ]
      2.6.32-rc6 #7
      -------------------------------------------------------
      chcp/30157 is trying to acquire lock:
       (&nilfs->ns_mount_mutex){+.+.+.}, at: [<fed7cfcc>] nilfs_cpfile_change_cpmode+0x46/0x752 [nilfs2]
      
      but task is already holding lock:
       (&nilfs->ns_segctor_sem){++++.+}, at: [<fed7ca32>] nilfs_transaction_begin+0xba/0x110 [nilfs2]
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 (&nilfs->ns_segctor_sem){++++.+}:
             [<c105799c>] __lock_acquire+0x109c/0x139d
             [<c1057d26>] lock_acquire+0x89/0xa0
             [<c14151e2>] down_read+0x31/0x45
             [<fed6d77b>] nilfs_attach_checkpoint+0x8f/0x16b [nilfs2]
             [<fed6e393>] nilfs_get_sb+0x3e7/0x653 [nilfs2]
             [<c10c0ccb>] vfs_kern_mount+0x8b/0x124
             [<c10c0db2>] do_kern_mount+0x37/0xc3
             [<c10d7517>] do_mount+0x64d/0x69d
             [<c10d75cd>] sys_mount+0x66/0x95
             [<c1002a14>] sysenter_do_call+0x12/0x32
      
      -> #1 (&type->s_umount_key#31/1){+.+.+.}:
             [<c105799c>] __lock_acquire+0x109c/0x139d
             [<c1057d26>] lock_acquire+0x89/0xa0
             [<c104c0f3>] down_write_nested+0x34/0x52
             [<c10c08fe>] sget+0x22e/0x389
             [<fed6e133>] nilfs_get_sb+0x187/0x653 [nilfs2]
             [<c10c0ccb>] vfs_kern_mount+0x8b/0x124
             [<c10c0db2>] do_kern_mount+0x37/0xc3
             [<c10d7517>] do_mount+0x64d/0x69d
             [<c10d75cd>] sys_mount+0x66/0x95
             [<c1002a14>] sysenter_do_call+0x12/0x32
      
      -> #0 (&nilfs->ns_mount_mutex){+.+.+.}:
             [<c1057727>] __lock_acquire+0xe27/0x139d
             [<c1057d26>] lock_acquire+0x89/0xa0
             [<c1414d63>] mutex_lock_nested+0x41/0x23e
             [<fed7cfcc>] nilfs_cpfile_change_cpmode+0x46/0x752 [nilfs2]
             [<fed801b2>] nilfs_ioctl+0x11a/0x7da [nilfs2]
             [<c10cca12>] vfs_ioctl+0x27/0x6e
             [<c10ccf93>] do_vfs_ioctl+0x491/0x4db
             [<c10cd022>] sys_ioctl+0x45/0x5f
             [<c1002a14>] sysenter_do_call+0x12/0x32
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      c1ea985c
  4. 08 11月, 2009 2 次提交
    • R
      nilfs2: fix missing cleanup of gc cache on error cases · c083234f
      Ryusuke Konishi 提交于
      This fixes an -rc1 regression brought by the commit:
      1cf58fa8 ("nilfs2: shorten freeze
      period due to GC in write operation v3").
      
      Although the patch moved out a function call of
      nilfs_ioctl_move_blocks() to nilfs_ioctl_clean_segments() from
      nilfs_ioctl_prepare_clean_segments(), it didn't move corresponding
      cleanup job needed for the error case.
      
      This will move the missing cleanup job to the destination function.
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Acked-by: NJiro SEKIBA <jir@unicus.jp>
      c083234f
    • R
      nilfs2: fix kernel oops in error case of nilfs_ioctl_move_blocks · 5399dd1f
      Ryusuke Konishi 提交于
      This fixes a kernel oops reported by Markus Trippelsdorf in the email
      titled "[NILFS users] kernel Oops while running nilfs_cleanerd".
      
      The oops was caused by a bug of error path in
      nilfs_ioctl_move_blocks() function, which was inlined in
      nilfs_ioctl_clean_segments().
      
      nilfs_ioctl_move_blocks checks duplication of blocks which will be
      moved in garbage collection.  But, the check should have be done
      within nilfs_ioctl_move_inode_block() to prevent list corruption among
      buffers storing the target blocks.
      
      To fix the kernel oops, this moves forward the duplication check
      before the list insertion.
      
      I also tested this for stable trees [2.6.30, 2.6.31].
      Reported-by: NMarkus Trippelsdorf <markus@trippelsdorf.de>
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Cc: stable <stable@kernel.org>
      5399dd1f
  5. 03 11月, 2009 3 次提交
  6. 02 10月, 2009 1 次提交
  7. 29 9月, 2009 2 次提交
    • R
      nilfs2: fix missing initialization of i_dir_start_lookup member · 3cc811bf
      Ryusuke Konishi 提交于
      The i_dir_start_lookup field in nilfs_inode_info objects should be
      cleared when the objects are allocated, but the the initialization was
      missing in case of reading from disk.  This adds the initialization.
      
      Since the variable just gives a start page on directory lookups, the
      bug was nonfatal until now.
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      3cc811bf
    • R
      nilfs2: fix missing zero-fill initialization of btree node cache · 1f28fcd9
      Ryusuke Konishi 提交于
      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: NYuri Chislov <yuri@itinteg.net>
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Cc: stable <stable@kernel.org>
      1f28fcd9
  8. 28 9月, 2009 1 次提交
  9. 22 9月, 2009 4 次提交
  10. 16 9月, 2009 1 次提交
  11. 14 9月, 2009 15 次提交