1. 08 12月, 2015 1 次提交
  2. 23 10月, 2015 3 次提交
  3. 15 10月, 2015 1 次提交
  4. 21 9月, 2015 1 次提交
    • D
      fs: fix data races on inode->i_flctx · 128a3785
      Dmitry Vyukov 提交于
      locks_get_lock_context() uses cmpxchg() to install i_flctx.
      cmpxchg() is a release operation which is correct. But it uses
      a plain load to load i_flctx. This is incorrect. Subsequent loads
      from i_flctx can hoist above the load of i_flctx pointer itself
      and observe uninitialized garbage there. This in turn can lead
      to corruption of ctx->flc_lock and other members.
      
      Documentation/memory-barriers.txt explicitly requires to use
      a barrier in such context:
      "A load-load control dependency requires a full read memory barrier".
      
      Use smp_load_acquire() in locks_get_lock_context() and in bunch
      of other functions that can proceed concurrently with
      locks_get_lock_context().
      
      The data race was found with KernelThreadSanitizer (KTSAN).
      Signed-off-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NJeff Layton <jeff.layton@primarydata.com>
      128a3785
  5. 01 9月, 2015 1 次提交
  6. 13 7月, 2015 3 次提交
  7. 17 4月, 2015 1 次提交
    • A
      proc: show locks in /proc/pid/fdinfo/X · 6c8c9031
      Andrey Vagin 提交于
      Let's show locks which are associated with a file descriptor in
      its fdinfo file.
      
      Currently we don't have a reliable way to determine who holds a lock.  We
      can find some information in /proc/locks, but PID which is reported there
      can be wrong.  For example, a process takes a lock, then forks a child and
      dies.  In this case /proc/locks contains the parent pid, which can be
      reused by another process.
      
      $ cat /proc/locks
      ...
      6: FLOCK  ADVISORY  WRITE 324 00:13:13431 0 EOF
      ...
      
      $ ps -C rpcbind
        PID TTY          TIME CMD
        332 ?        00:00:00 rpcbind
      
      $ cat /proc/332/fdinfo/4
      pos:	0
      flags:	0100000
      mnt_id:	22
      lock:	1: FLOCK  ADVISORY  WRITE 324 00:13:13431 0 EOF
      
      $ ls -l /proc/332/fd/4
      lr-x------ 1 root root 64 Mar  5 14:43 /proc/332/fd/4 -> /run/rpcbind.lock
      
      $ ls -l /proc/324/fd/
      total 0
      lrwx------ 1 root root 64 Feb 27 14:50 0 -> /dev/pts/0
      lrwx------ 1 root root 64 Feb 27 14:50 1 -> /dev/pts/0
      lrwx------ 1 root root 64 Feb 27 14:49 2 -> /dev/pts/0
      
      You can see that the process with the 324 pid doesn't hold the lock.
      
      This information is required for proper dumping and restoring file
      locks.
      Signed-off-by: NAndrey Vagin <avagin@openvz.org>
      Cc: Jonathan Corbet <corbet@lwn.net>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Acked-by: NJeff Layton <jlayton@poochiereds.net>
      Acked-by: N"J. Bruce Fields" <bfields@fieldses.org>
      Acked-by: NCyrill Gorcunov <gorcunov@openvz.org>
      Cc: Pavel Emelyanov <xemul@parallels.com>
      Cc: Joe Perches <joe@perches.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6c8c9031
  8. 03 4月, 2015 7 次提交
  9. 27 3月, 2015 1 次提交
  10. 14 3月, 2015 1 次提交
  11. 05 3月, 2015 1 次提交
    • J
      locks: fix fasync_struct memory leak in lease upgrade/downgrade handling · 0164bf02
      Jeff Layton 提交于
      Commit 8634b51f (locks: convert lease handling to file_lock_context)
      introduced a regression in the handling of lease upgrade/downgrades.
      
      In the event that we already have a lease on a file and are going to
      either upgrade or downgrade it, we skip doing any list insertion or
      deletion and simply re-call lm_setup on the existing lease.
      
      As of commit 8634b51f however, we end up calling lm_setup on the
      lease that was passed in, instead of on the existing lease. This causes
      us to leak the fasync_struct that was allocated in the event that there
      was not already an existing one (as it always appeared that there
      wasn't one).
      
      Fixes: 8634b51f (locks: convert lease handling to file_lock_context)
      Reported-and-Tested-by: NDaniel Wagner <daniel.wagner@bmw-carit.de>
      Signed-off-by: NJeff Layton <jeff.layton@primarydata.com>
      0164bf02
  12. 18 2月, 2015 3 次提交
    • J
      locks: fix list insertion when lock is split in two · 2e2f756f
      Jeff Layton 提交于
      In the case where we're splitting a lock in two, the current code
      the new "left" lock in the incorrect spot. It's inserted just
      before "right" when it should instead be inserted just before the
      new lock.
      
      When we add a new lock, set "fl" to that value so that we can
      add "left" before it.
      Reported-by: NAl Viro <viro@ZenIV.linux.org.uk>
      Signed-off-by: NJeff Layton <jeff.layton@primarydata.com>
      2e2f756f
    • J
      locks: remove conditional lock release in middle of flock_lock_file · 267f1128
      Jeff Layton 提交于
      As Linus pointed out:
      
          Say we have an existing flock, and now do a new one that conflicts. I
          see what looks like three separate bugs.
      
           - We go through the first loop, find a lock of another type, and
          delete it in preparation for replacing it
      
           - we *drop* the lock context spinlock.
      
           - BUG #1? So now there is no lock at all, and somebody can come in
          and see that unlocked state. Is that really valid?
      
           - another thread comes in while the first thread dropped the lock
          context lock, and wants to add its own lock. It doesn't see the
          deleted or pending locks, so it just adds it
      
           - the first thread gets the context spinlock again, and adds the lock
          that replaced the original
      
           - BUG #2? So now there are *two* locks on the thing, and the next
          time you do an unlock (or when you close the file), it will only
          remove/replace the first one.
      
      ...remove the "drop the spinlock" code in the middle of this function as
      it has always been suspicious. This should eliminate the potential race
      that can leave two locks for the same struct file on the list.
      
      He also pointed out another thing as a bug -- namely that you
      flock_lock_file removes the lock from the list unconditionally when
      doing a lock upgrade, without knowing whether it'll be able to set the
      new lock. Bruce pointed out that this is expected behavior and may help
      prevent certain deadlock situations.
      
      We may want to revisit that at some point, but it's probably best that
      we do so in the context of a different patchset.
      Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: NJeff Layton <jeff.layton@primarydata.com>
      267f1128
    • J
      locks: only remove leases associated with the file being closed · c4e136cd
      Jeff Layton 提交于
      We don't want to remove all leases just because one filp was closed.
      Signed-off-by: NJeff Layton <jeff.layton@primarydata.com>
      c4e136cd
  13. 17 2月, 2015 1 次提交
  14. 03 2月, 2015 2 次提交
    • C
      fs: add FL_LAYOUT lease type · 11afe9f7
      Christoph Hellwig 提交于
      This (ab-)uses the file locking code to allow filesystems to recall
      outstanding pNFS layouts on a file.  This new lease type is similar but
      not quite the same as FL_DELEG.  A FL_LAYOUT lease can always be granted,
      an a per-filesystem lock (XFS iolock for the initial implementation)
      ensures not FL_LAYOUT leases granted when we would need to recall them.
      
      Also included are changes that allow multiple outstanding read
      leases of different types on the same file as long as they have a
      differnt owner.  This wasn't a problem until now as nfsd never set
      FL_LEASE leases, and no one else used FL_DELEG leases, but given that
      nfsd will also issues FL_LAYOUT leases we will have to handle it now.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      11afe9f7
    • C
      fs: track fl_owner for leases · 2ab99ee1
      Christoph Hellwig 提交于
      Just like for other lock types we should allow different owners to have
      a read lease on a file.  Currently this can't happen, but with the addition
      of pNFS layout leases we'll need this feature.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      2ab99ee1
  15. 22 1月, 2015 1 次提交
  16. 17 1月, 2015 10 次提交
  17. 13 1月, 2015 1 次提交
  18. 08 10月, 2014 1 次提交