1. 12 6月, 2009 9 次提交
  2. 30 5月, 2009 1 次提交
  3. 23 5月, 2009 1 次提交
  4. 22 5月, 2009 1 次提交
  5. 12 5月, 2009 1 次提交
    • R
      nilfs2: check size of array structured data exchanged via ioctls · 83aca8f4
      Ryusuke Konishi 提交于
      Although some ioctls of nilfs2 exchange data in the form of indirectly
      referenced array, some of them lack size check on the array elements.
      
      This inserts the missing checks and rejects requests if data of ioctl
      does not have a valid format.
      
      We usually don't have to check size of structures that we associated
      with ioctl commands because the size is tested implicitly for
      identifying ioctl command; the checks this patch adds are for the
      cases where the implicit check is not applied.
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      83aca8f4
  6. 11 5月, 2009 2 次提交
    • R
      nilfs2: fix lock order reversal in nilfs_clean_segments ioctl · 4f6b8288
      Ryusuke Konishi 提交于
      This is a companion patch to ("nilfs2: fix possible circular locking
      for get information ioctls").
      
      This corrects lock order reversal between mm->mmap_sem and
      nilfs->ns_segctor_sem in nilfs_clean_segments() which was detected by
      lockdep check:
      
       =======================================================
       [ INFO: possible circular locking dependency detected ]
       2.6.30-rc3-nilfs-00003-g360bdc1 #7
       -------------------------------------------------------
       mmap/5294 is trying to acquire lock:
        (&nilfs->ns_segctor_sem){++++.+}, at: [<d0d0e846>] nilfs_transaction_begin+0xb6/0x10c [nilfs2]
      
       but task is already holding lock:
        (&mm->mmap_sem){++++++}, at: [<c043700a>] do_page_fault+0x1d8/0x30a
      
       which lock already depends on the new lock.
      
       the existing dependency chain (in reverse order) is:
      
       -> #1 (&mm->mmap_sem){++++++}:
              [<c01470a5>] __lock_acquire+0x1066/0x13b0
              [<c01474a9>] lock_acquire+0xba/0xdd
              [<c01836bc>] might_fault+0x68/0x88
              [<c023c61d>] copy_from_user+0x2a/0x111
              [<d0d120d0>] nilfs_ioctl_prepare_clean_segments+0x1d/0xf1 [nilfs2]
              [<d0d0e2aa>] nilfs_clean_segments+0x6d/0x1b9 [nilfs2]
              [<d0d11f68>] nilfs_ioctl+0x2ad/0x318 [nilfs2]
              [<c01a3be7>] vfs_ioctl+0x22/0x69
              [<c01a408e>] do_vfs_ioctl+0x460/0x499
              [<c01a4107>] sys_ioctl+0x40/0x5a
              [<c01031a4>] sysenter_do_call+0x12/0x38
              [<ffffffff>] 0xffffffff
      
       -> #0 (&nilfs->ns_segctor_sem){++++.+}:
              [<c0146e0b>] __lock_acquire+0xdcc/0x13b0
              [<c01474a9>] lock_acquire+0xba/0xdd
              [<c0433f1d>] down_read+0x2a/0x3e
              [<d0d0e846>] nilfs_transaction_begin+0xb6/0x10c [nilfs2]
              [<d0cfe0e5>] nilfs_page_mkwrite+0xe7/0x154 [nilfs2]
              [<c0183b0b>] __do_fault+0x165/0x376
              [<c01855cd>] handle_mm_fault+0x287/0x5d1
              [<c043712d>] do_page_fault+0x2fb/0x30a
              [<c0435462>] error_code+0x72/0x78
              [<ffffffff>] 0xffffffff
      
      where nilfs_clean_segments() holds:
      
        nilfs->ns_segctor_sem -> copy_from_user()
                                   --> page fault -> mm->mmap_sem
      
      And, page fault path may hold:
      
        page fault -> mm->mmap_sem
               --> nilfs_page_mkwrite() -> nilfs->ns_segctor_sem
      
      Even though nilfs_clean_segments() does not perform write access on
      given user pages, it may cause deadlock because nilfs->ns_segctor_sem
      is shared per device and mm->mmap_sem can be shared with other tasks.
      
      To avoid this problem, this patch moves all calls of copy_from_user()
      outside the nilfs->ns_segctor_sem lock in the ioctl.
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      4f6b8288
    • R
      nilfs2: fix possible circular locking for get information ioctls · 47eb6b9c
      Ryusuke Konishi 提交于
      This is one of two patches which are to correct possible circular
      locking between mm->mmap_sem and nilfs->ns_segctor_sem.
      
      The problem was detected by lockdep check as follows:
      
       =======================================================
       [ INFO: possible circular locking dependency detected ]
       2.6.30-rc3-nilfs-00002-g3552613 #6
       -------------------------------------------------------
       mmap/5418 is trying to acquire lock:
       (&nilfs->ns_segctor_sem){++++.+}, at: [<d0d0e852>] nilfs_transaction_begin+0xb6/0x10c [nilfs2]
      
       but task is already holding lock:
       (&mm->mmap_sem){++++++}, at: [<c043700a>] do_page_fault+0x1d8/0x30a
      
       which lock already depends on the new lock.
      
       the existing dependency chain (in reverse order) is:
      
       -> #1 (&mm->mmap_sem){++++++}:
       [<c01470a5>] __lock_acquire+0x1066/0x13b0
       [<c01474a9>] lock_acquire+0xba/0xdd
       [<c01836bc>] might_fault+0x68/0x88
       [<c023c730>] copy_to_user+0x2c/0xfc
       [<d0d11b4f>] nilfs_ioctl_wrap_copy+0x103/0x160 [nilfs2]
       [<d0d11fa9>] nilfs_ioctl+0x30a/0x3b0 [nilfs2]
       [<c01a3be7>] vfs_ioctl+0x22/0x69
       [<c01a408e>] do_vfs_ioctl+0x460/0x499
       [<c01a4107>] sys_ioctl+0x40/0x5a
       [<c01031a4>] sysenter_do_call+0x12/0x38
       [<ffffffff>] 0xffffffff
      
       -> #0 (&nilfs->ns_segctor_sem){++++.+}:
       [<c0146e0b>] __lock_acquire+0xdcc/0x13b0
       [<c01474a9>] lock_acquire+0xba/0xdd
       [<c0433f1d>] down_read+0x2a/0x3e
       [<d0d0e852>] nilfs_transaction_begin+0xb6/0x10c [nilfs2]
       [<d0cfe0e5>] nilfs_page_mkwrite+0xe7/0x154 [nilfs2]
       [<c0183b0b>] __do_fault+0x165/0x376
       [<c01855cd>] handle_mm_fault+0x287/0x5d1
       [<c043712d>] do_page_fault+0x2fb/0x30a
       [<c0435462>] error_code+0x72/0x78
       [<ffffffff>] 0xffffffff
      
       other info that might help us debug this:
      
       1 lock held by mmap/5418:
       #0:  (&mm->mmap_sem){++++++}, at: [<c043700a>] do_page_fault+0x1d8/0x30a
      
       stack backtrace:
       Pid: 5418, comm: mmap Not tainted 2.6.30-rc3-nilfs-00002-g3552613 #6
       Call Trace:
       [<c0432145>] ? printk+0xf/0x12
       [<c0145c48>] print_circular_bug_tail+0xaa/0xb5
       [<c0146e0b>] __lock_acquire+0xdcc/0x13b0
       [<d0d10149>] ? nilfs_sufile_get_stat+0x1e/0x105 [nilfs2]
       [<c013b59a>] ? up_read+0x16/0x2c
       [<d0d10225>] ? nilfs_sufile_get_stat+0xfa/0x105 [nilfs2]
       [<c01474a9>] lock_acquire+0xba/0xdd
       [<d0d0e852>] ? nilfs_transaction_begin+0xb6/0x10c [nilfs2]
       [<c0433f1d>] down_read+0x2a/0x3e
       [<d0d0e852>] ? nilfs_transaction_begin+0xb6/0x10c [nilfs2]
       [<d0d0e852>] nilfs_transaction_begin+0xb6/0x10c [nilfs2]
       [<d0cfe0e5>] nilfs_page_mkwrite+0xe7/0x154 [nilfs2]
       [<c0183b0b>] __do_fault+0x165/0x376
       [<c01855cd>] handle_mm_fault+0x287/0x5d1
       [<c043700a>] ? do_page_fault+0x1d8/0x30a
       [<c013b54f>] ? down_read_trylock+0x39/0x43
       [<c043712d>] do_page_fault+0x2fb/0x30a
       [<c0436e32>] ? do_page_fault+0x0/0x30a
       [<c0435462>] error_code+0x72/0x78
       [<c0436e32>] ? do_page_fault+0x0/0x30a
      
      This makes the lock granularity of nilfs->ns_segctor_sem finer than
      that of the mmap semaphore for ioctl commands except
      nilfs_clean_segments().
      
      The successive patch ("nilfs2: fix lock order reversal in
      nilfs_clean_segments ioctl") is required to fully resolve the problem.
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      47eb6b9c
  7. 10 5月, 2009 1 次提交
  8. 09 5月, 2009 2 次提交
    • R
      nilfs2: fix circular locking dependency of writer mutex · 201913ed
      Ryusuke Konishi 提交于
      This fixes the following circular locking dependency problem:
      
       =======================================================
       [ INFO: possible circular locking dependency detected ]
       2.6.30-rc3 #5
       -------------------------------------------------------
       segctord/3895 is trying to acquire lock:
        (&nilfs->ns_writer_mutex){+.+...}, at: [<d0d02172>]
         nilfs_mdt_get_block+0x89/0x20f [nilfs2]
      
       but task is already holding lock:
        (&bmap->b_sem){++++..}, at: [<d0d02d99>]
         nilfs_bmap_propagate+0x14/0x2e [nilfs2]
      
       which lock already depends on the new lock.
      
      The bugfix is done by replacing call sites of nilfs_get_writer() which
      are never called from read-only context with direct dereferencing of
      pointer to a writable FS-instance.
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      201913ed
    • R
      nilfs2: fix possible recovery failure due to block creation without writer · 85c2a74f
      Ryusuke Konishi 提交于
      Some function calls in nilfs_prepare_segment_for_recovery() may fail
      because they can create blocks on meta data files without configuring
      a writable FS-instance.  Concretely, nilfs_mdt_create_block() routine
      of meta data files will fail in that case.
      
      This fixes the problem by temporarily attaching a writable FS-instace
      during the function is called.
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      85c2a74f
  9. 13 4月, 2009 8 次提交
  10. 07 4月, 2009 14 次提交