1. 23 10月, 2010 2 次提交
  2. 25 12月, 2009 1 次提交
  3. 20 11月, 2009 2 次提交
  4. 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
  5. 14 9月, 2009 1 次提交
  6. 05 7月, 2009 1 次提交
  7. 12 6月, 2009 1 次提交
  8. 10 6月, 2009 2 次提交
    • R
      nilfs2: return EBUSY against delete request on snapshot · 30c25be7
      Ryusuke Konishi 提交于
      This helps userland programs like the rmcp command to distinguish
      error codes returned against a checkpoint removal request.
      
      Previously -EPERM was returned, and not discriminable from real
      permission errors.  This also allows removal of the latest checkpoint
      because the deletion leads to create a new checkpoint, and thus it's
      harmless for the filesystem.
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      30c25be7
    • 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
  9. 30 5月, 2009 1 次提交
  10. 07 4月, 2009 6 次提交