1. 23 10月, 2010 3 次提交
  2. 05 10月, 2010 1 次提交
  3. 31 3月, 2010 1 次提交
  4. 30 3月, 2010 1 次提交
    • T
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking... · 5a0e3ad6
      Tejun Heo 提交于
      include cleanup: Update gfp.h and slab.h includes to prepare for breaking implicit slab.h inclusion from percpu.h
      
      percpu.h is included by sched.h and module.h and thus ends up being
      included when building most .c files.  percpu.h includes slab.h which
      in turn includes gfp.h making everything defined by the two files
      universally available and complicating inclusion dependencies.
      
      percpu.h -> slab.h dependency is about to be removed.  Prepare for
      this change by updating users of gfp and slab facilities include those
      headers directly instead of assuming availability.  As this conversion
      needs to touch large number of source files, the following script is
      used as the basis of conversion.
      
        http://userweb.kernel.org/~tj/misc/slabh-sweep.py
      
      The script does the followings.
      
      * Scan files for gfp and slab usages and update includes such that
        only the necessary includes are there.  ie. if only gfp is used,
        gfp.h, if slab is used, slab.h.
      
      * When the script inserts a new include, it looks at the include
        blocks and try to put the new include such that its order conforms
        to its surrounding.  It's put in the include block which contains
        core kernel includes, in the same order that the rest are ordered -
        alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
        doesn't seem to be any matching order.
      
      * If the script can't find a place to put a new include (mostly
        because the file doesn't have fitting include block), it prints out
        an error message indicating which .h file needs to be added to the
        file.
      
      The conversion was done in the following steps.
      
      1. The initial automatic conversion of all .c files updated slightly
         over 4000 files, deleting around 700 includes and adding ~480 gfp.h
         and ~3000 slab.h inclusions.  The script emitted errors for ~400
         files.
      
      2. Each error was manually checked.  Some didn't need the inclusion,
         some needed manual addition while adding it to implementation .h or
         embedding .c file was more appropriate for others.  This step added
         inclusions to around 150 files.
      
      3. The script was run again and the output was compared to the edits
         from #2 to make sure no file was left behind.
      
      4. Several build tests were done and a couple of problems were fixed.
         e.g. lib/decompress_*.c used malloc/free() wrappers around slab
         APIs requiring slab.h to be added manually.
      
      5. The script was run on all .h files but without automatically
         editing them as sprinkling gfp.h and slab.h inclusions around .h
         files could easily lead to inclusion dependency hell.  Most gfp.h
         inclusion directives were ignored as stuff from gfp.h was usually
         wildly available and often used in preprocessor macros.  Each
         slab.h inclusion directive was examined and added manually as
         necessary.
      
      6. percpu.h was updated not to include slab.h.
      
      7. Build test were done on the following configurations and failures
         were fixed.  CONFIG_GCOV_KERNEL was turned off for all tests (as my
         distributed build env didn't work with gcov compiles) and a few
         more options had to be turned off depending on archs to make things
         build (like ipr on powerpc/64 which failed due to missing writeq).
      
         * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
         * powerpc and powerpc64 SMP allmodconfig
         * sparc and sparc64 SMP allmodconfig
         * ia64 SMP allmodconfig
         * s390 SMP allmodconfig
         * alpha SMP allmodconfig
         * um on x86_64 SMP allmodconfig
      
      8. percpu.h modifications were reverted so that it could be applied as
         a separate patch and serve as bisection point.
      
      Given the fact that I had only a couple of failures from tests on step
      6, I'm fairly confident about the coverage of this conversion patch.
      If there is a breakage, it's likely to be something in one of the arch
      headers which should be easily discoverable easily on most builds of
      the specific arch.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Guess-its-ok-by: NChristoph Lameter <cl@linux-foundation.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>
      5a0e3ad6
  5. 20 2月, 2010 1 次提交
  6. 13 2月, 2010 1 次提交
  7. 25 12月, 2009 1 次提交
  8. 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
  9. 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
  10. 14 9月, 2009 1 次提交
    • J
      nilfs2: shorten freeze period due to GC in write operation v3 · 1cf58fa8
      Jiro SEKIBA 提交于
      This is a re-revised patch to shorten freeze period.
      This version include a fix of the bug Konishi-san mentioned last time.
      
      When GC is runnning, GC moves live block to difference segments.
      Copying live blocks into memory is done in a transaction,
      however it is not necessarily to be in the transaction.
      This patch will get the nilfs_ioctl_move_blocks() out from
      transaction lock and put it before the transaction.
      
      I ran sysbench fileio test against nilfs partition.
      I copied some DVD/CD images and created snapshot to create live blocks
      before starting the benchmark.
      
      Followings are summary of rc8 and rc8 w/ the patch of per-request
      statistics, which is min/max and avg.  I ran each test three times and
      bellow is average of those numers.
      
      According to this benchmark result, average time is slightly degrated.
      However, worstcase (max) result is significantly improved.
      This can address a few seconds write freeze.
      
      - random write per-request performance of rc8
       min   0.843ms
       max 680.406ms
       avg   3.050ms
      - random write per-request performance of rc8 w/ this patch
       min   0.843ms -> 100.00%
       max 380.490ms ->  55.90%
       avg   3.233ms -> 106.00%
      
      - sequential write per-request performance of rc8
       min   0.736ms
       max 774.343ms
       avg   2.883ms
      - sequential write per-request performance of rc8 w/ this patch
       min   0.720ms ->  97.80%
       max  644.280ms->  83.20%
       avg   3.130ms -> 108.50%
      
      -----8<-----8<-----nilfs_cleanerd.conf-----8<-----8<-----
      protection_period       150
      selection_policy        timestamp       # timestamp in ascend order
      nsegments_per_clean     2
      cleaning_interval       2
      retry_interval          60
      use_mmap
      log_priority            info
      -----8<-----8<-----nilfs_cleanerd.conf-----8<-----8<-----
      Signed-off-by: NJiro SEKIBA <jir@unicus.jp>
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      1cf58fa8
  11. 10 6月, 2009 2 次提交
    • R
      nilfs2: allow future expansion of metadata read out via get info ioctl · 003ff182
      Ryusuke Konishi 提交于
      Nilfs has some ioctl commands to read out metadata from meta data
      files:
      
       - NILFS_IOCTL_GET_CPINFO for checkpoint file,
       - NILFS_IOCTL_GET_SUINFO for segment usage file, and
       - NILFS_IOCTL_GET_VINFO for Disk Address Transalation (DAT) file,
         respectively.
      
      Every routine on these metadata files is implemented so that it allows
      future expansion of on-disk format.  But, the above ioctl commands do
      not support expansion even though nilfs_argv structure can handle
      arbitrary size for data exchanged via ioctl.
      
      This allows future expansion of the following structures which give
      basic format of the "get information" ioctls:
      
       - struct nilfs_cpinfo
       - struct nilfs_suinfo
       - struct nilfs_vinfo
      
      So, this introduces forward compatility of such ioctl commands.
      
      In this patch, a sanity check in nilfs_ioctl_get_info() function is
      changed to accept larger data structure [1], and metadata read
      routines are rewritten so that they become compatible for larger
      structures; the routines will just ignore the remaining fields which
      the current version of nilfs doesn't know.
      
      [1] The ioctl function already has another upper limit (PAGE_SIZE
          against a structure, which appears in nilfs_ioctl_wrap_copy
          function), and this will not cause security problem.
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      003ff182
    • R
      nilfs2: eliminate removal list of segments · 071cb4b8
      Ryusuke Konishi 提交于
      This will clean up the removal list of segments and the related
      functions from segment.c and ioctl.c, which have hurt code
      readability.
      
      This elimination is applied by using nilfs_sufile_updatev() previously
      introduced in the patch ("nilfs2: add sufile function that can modify
      multiple segment usages").
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      071cb4b8
  12. 22 5月, 2009 1 次提交
  13. 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
  14. 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
  15. 09 5月, 2009 1 次提交
    • 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
  16. 07 4月, 2009 10 次提交