1. 18 9月, 2012 1 次提交
    • E
      userns: Pass a userns parameter into posix_acl_to_xattr and posix_acl_from_xattr · 5f3a4a28
      Eric W. Biederman 提交于
       - Pass the user namespace the uid and gid values in the xattr are stored
         in into posix_acl_from_xattr.
      
       - Pass the user namespace kuid and kgid values should be converted into
         when storing uid and gid values in an xattr in posix_acl_to_xattr.
      
      - Modify all callers of posix_acl_from_xattr and posix_acl_to_xattr to
        pass in &init_user_ns.
      
      In the short term this change is not strictly needed but it makes the
      code clearer.  In the longer term this change is necessary to be able to
      mount filesystems outside of the initial user namespace that natively
      store posix acls in the linux xattr format.
      
      Cc: Theodore Tso <tytso@mit.edu>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andreas Dilger <adilger.kernel@dilger.ca>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      5f3a4a28
  2. 23 7月, 2012 1 次提交
  3. 14 7月, 2012 2 次提交
  4. 31 5月, 2012 4 次提交
  5. 14 5月, 2012 9 次提交
  6. 08 5月, 2012 1 次提交
    • J
      jffs2: Fix lock acquisition order bug in gc path · 226bb7df
      Josh Cartwright 提交于
      The locking policy is such that the erase_complete_block spinlock is
      nested within the alloc_sem mutex.  This fixes a case in which the
      acquisition order was erroneously reversed.  This issue was caught by
      the following lockdep splat:
      
         =======================================================
         [ INFO: possible circular locking dependency detected ]
         3.0.5 #1
         -------------------------------------------------------
         jffs2_gcd_mtd6/299 is trying to acquire lock:
          (&c->alloc_sem){+.+.+.}, at: [<c01f7714>] jffs2_garbage_collect_pass+0x314/0x890
      
         but task is already holding lock:
          (&(&c->erase_completion_lock)->rlock){+.+...}, at: [<c01f7708>] jffs2_garbage_collect_pass+0x308/0x890
      
         which lock already depends on the new lock.
      
         the existing dependency chain (in reverse order) is:
      
         -> #1 (&(&c->erase_completion_lock)->rlock){+.+...}:
                [<c008bec4>] validate_chain+0xe6c/0x10bc
                [<c008c660>] __lock_acquire+0x54c/0xba4
                [<c008d240>] lock_acquire+0xa4/0x114
                [<c046780c>] _raw_spin_lock+0x3c/0x4c
                [<c01f744c>] jffs2_garbage_collect_pass+0x4c/0x890
                [<c01f937c>] jffs2_garbage_collect_thread+0x1b4/0x1cc
                [<c0071a68>] kthread+0x98/0xa0
                [<c000f264>] kernel_thread_exit+0x0/0x8
      
         -> #0 (&c->alloc_sem){+.+.+.}:
                [<c008ad2c>] print_circular_bug+0x70/0x2c4
                [<c008c08c>] validate_chain+0x1034/0x10bc
                [<c008c660>] __lock_acquire+0x54c/0xba4
                [<c008d240>] lock_acquire+0xa4/0x114
                [<c0466628>] mutex_lock_nested+0x74/0x33c
                [<c01f7714>] jffs2_garbage_collect_pass+0x314/0x890
                [<c01f937c>] jffs2_garbage_collect_thread+0x1b4/0x1cc
                [<c0071a68>] kthread+0x98/0xa0
                [<c000f264>] kernel_thread_exit+0x0/0x8
      
         other info that might help us debug this:
      
          Possible unsafe locking scenario:
      
                CPU0                    CPU1
                ----                    ----
           lock(&(&c->erase_completion_lock)->rlock);
                                        lock(&c->alloc_sem);
                                        lock(&(&c->erase_completion_lock)->rlock);
           lock(&c->alloc_sem);
      
          *** DEADLOCK ***
      
         1 lock held by jffs2_gcd_mtd6/299:
          #0:  (&(&c->erase_completion_lock)->rlock){+.+...}, at: [<c01f7708>] jffs2_garbage_collect_pass+0x308/0x890
      
         stack backtrace:
         [<c00155dc>] (unwind_backtrace+0x0/0x100) from [<c0463dc0>] (dump_stack+0x20/0x24)
         [<c0463dc0>] (dump_stack+0x20/0x24) from [<c008ae84>] (print_circular_bug+0x1c8/0x2c4)
         [<c008ae84>] (print_circular_bug+0x1c8/0x2c4) from [<c008c08c>] (validate_chain+0x1034/0x10bc)
         [<c008c08c>] (validate_chain+0x1034/0x10bc) from [<c008c660>] (__lock_acquire+0x54c/0xba4)
         [<c008c660>] (__lock_acquire+0x54c/0xba4) from [<c008d240>] (lock_acquire+0xa4/0x114)
         [<c008d240>] (lock_acquire+0xa4/0x114) from [<c0466628>] (mutex_lock_nested+0x74/0x33c)
         [<c0466628>] (mutex_lock_nested+0x74/0x33c) from [<c01f7714>] (jffs2_garbage_collect_pass+0x314/0x890)
         [<c01f7714>] (jffs2_garbage_collect_pass+0x314/0x890) from [<c01f937c>] (jffs2_garbage_collect_thread+0x1b4/0x1cc)
         [<c01f937c>] (jffs2_garbage_collect_thread+0x1b4/0x1cc) from [<c0071a68>] (kthread+0x98/0xa0)
         [<c0071a68>] (kthread+0x98/0xa0) from [<c000f264>] (kernel_thread_exit+0x0/0x8)
      
      This was introduce in '81cfc9f1 jffs2: Fix serious write stall due to erase'.
      
      Cc: stable@kernel.org [2.6.37+]
      Signed-off-by: NJosh Cartwright <joshc@linux.com>
      Signed-off-by: NArtem Bityutskiy <artem.bityutskiy@linux.intel.com>
      Signed-off-by: NDavid Woodhouse <David.Woodhouse@intel.com>
      226bb7df
  7. 06 5月, 2012 1 次提交
  8. 27 3月, 2012 11 次提交
  9. 21 3月, 2012 1 次提交
  10. 10 2月, 2012 1 次提交
  11. 11 1月, 2012 1 次提交
  12. 10 1月, 2012 7 次提交