1. 17 4月, 2015 1 次提交
  2. 04 4月, 2014 1 次提交
  3. 31 7月, 2012 1 次提交
    • R
      nilfs2: fix timing issue between rmcp and chcp ioctls · fe0627e7
      Ryusuke Konishi 提交于
      The checkpoint deletion ioctl (rmcp ioctl) has potential for breaking
      snapshot because it is not fully exclusive with checkpoint mode change
      ioctl (chcp ioctl).
      
      The rmcp ioctl first tests if the specified checkpoint is a snapshot or
      not within nilfs_cpfile_delete_checkpoint function, and then calls
      nilfs_cpfile_delete_checkpoints function to actually invalidate the
      checkpoint only if it's not a snapshot.  However, the checkpoint can be
      changed into a snapshot by the chcp ioctl between these two operations.
      In that case, calling nilfs_cpfile_delete_checkpoints() wrongly
      invalidates the snapshot, which leads to snapshot list corruption and
      snapshot count mismatch.
      
      This fixes the issue by changing nilfs_cpfile_delete_checkpoints() so
      that it reconfirms the target checkpoints are snapshot or not.
      
      This second check is exclusive with the chcp operation since it is
      protected by an existing semaphore.
      Signed-off-by: NRyusuke Konishi <konishi.ryusuke@lab.ntt.co.jp>
      Cc: Fernando Luis Vazquez Cao <fernando@oss.ntt.co.jp>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      fe0627e7
  4. 20 3月, 2012 1 次提交
  5. 10 5月, 2011 1 次提交
  6. 23 10月, 2010 2 次提交
  7. 25 12月, 2009 1 次提交
  8. 20 11月, 2009 2 次提交
  9. 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
  10. 14 9月, 2009 1 次提交
  11. 05 7月, 2009 1 次提交
  12. 12 6月, 2009 1 次提交
  13. 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
  14. 30 5月, 2009 1 次提交
  15. 07 4月, 2009 6 次提交