1. 15 5月, 2017 1 次提交
  2. 31 1月, 2017 2 次提交
  3. 02 12月, 2016 1 次提交
  4. 19 11月, 2016 1 次提交
    • T
      NFSv4: Fix CLOSE races with OPEN · 3e7dfb16
      Trond Myklebust 提交于
      If the reply to a successful CLOSE call races with an OPEN to the same
      file, we can end up scribbling over the stateid that represents the
      new open state.
      The race looks like:
      
        Client				Server
        ======				======
      
        CLOSE stateid A on file "foo"
      					CLOSE stateid A, return stateid C
        OPEN file "foo"
      					OPEN "foo", return stateid B
        Receive reply to OPEN
        Reset open state for "foo"
        Associate stateid B to "foo"
      
        Receive CLOSE for A
        Reset open state for "foo"
        Replace stateid B with C
      
      The fix is to examine the argument of the CLOSE, and check for a match
      with the current stateid "other" field. If the two do not match, then
      the above race occurred, and we should just ignore the CLOSE.
      Reported-by: NBenjamin Coddington <bcodding@redhat.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      3e7dfb16
  5. 28 9月, 2016 2 次提交
  6. 23 9月, 2016 1 次提交
  7. 20 9月, 2016 3 次提交
  8. 06 8月, 2016 1 次提交
  9. 21 7月, 2016 1 次提交
  10. 01 7月, 2016 1 次提交
  11. 18 5月, 2016 2 次提交
  12. 08 10月, 2015 1 次提交
  13. 18 8月, 2015 1 次提交
  14. 24 6月, 2015 1 次提交
  15. 04 2月, 2015 2 次提交
  16. 24 1月, 2015 1 次提交
  17. 26 11月, 2014 1 次提交
  18. 01 10月, 2014 1 次提交
  19. 09 9月, 2014 1 次提交
    • J
      nfs: revert "nfs4: queue free_lock_state job submission to nfsiod" · 0c0e0d3c
      Jeff Layton 提交于
      This reverts commit 49a4bda2.
      
      Christoph reported an oops due to the above commit:
      
      generic/089 242s ...[ 2187.041239] general protection fault: 0000 [#1]
      SMP
      [ 2187.042899] Modules linked in:
      [ 2187.044000] CPU: 0 PID: 11913 Comm: kworker/0:1 Not tainted 3.16.0-rc6+ #1151
      [ 2187.044287] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
      [ 2187.044287] Workqueue: nfsiod free_lock_state_work
      [ 2187.044287] task: ffff880072b50cd0 ti: ffff88007a4ec000 task.ti: ffff88007a4ec000
      [ 2187.044287] RIP: 0010:[<ffffffff81361ca6>]  [<ffffffff81361ca6>] free_lock_state_work+0x16/0x30
      [ 2187.044287] RSP: 0018:ffff88007a4efd58  EFLAGS: 00010296
      [ 2187.044287] RAX: 6b6b6b6b6b6b6b6b RBX: ffff88007a947ac0 RCX: 8000000000000000
      [ 2187.044287] RDX: ffffffff826af9e0 RSI: ffff88007b093c00 RDI: ffff88007b093db8
      [ 2187.044287] RBP: ffff88007a4efd58 R08: ffffffff832d3e10 R09: 000001c40efc0000
      [ 2187.044287] R10: 0000000000000000 R11: 0000000000059e30 R12: ffff88007fc13240
      [ 2187.044287] R13: ffff88007fc18b00 R14: ffff88007b093db8 R15: 0000000000000000
      [ 2187.044287] FS:  0000000000000000(0000) GS:ffff88007fc00000(0000) knlGS:0000000000000000
      [ 2187.044287] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      [ 2187.044287] CR2: 00007f93ec33fb80 CR3: 0000000079dc2000 CR4: 00000000000006f0
      [ 2187.044287] Stack:
      [ 2187.044287]  ffff88007a4efdd8 ffffffff810cc877 ffffffff810cc80d ffff88007fc13258
      [ 2187.044287]  000000007a947af0 0000000000000000 ffffffff8353ccc8 ffffffff82b6f3d0
      [ 2187.044287]  0000000000000000 ffffffff82267679 ffff88007a4efdd8 ffff88007fc13240
      [ 2187.044287] Call Trace:
      [ 2187.044287]  [<ffffffff810cc877>] process_one_work+0x1c7/0x490
      [ 2187.044287]  [<ffffffff810cc80d>] ? process_one_work+0x15d/0x490
      [ 2187.044287]  [<ffffffff810cd569>] worker_thread+0x119/0x4f0
      [ 2187.044287]  [<ffffffff810fbbad>] ? trace_hardirqs_on+0xd/0x10
      [ 2187.044287]  [<ffffffff810cd450>] ? init_pwq+0x190/0x190
      [ 2187.044287]  [<ffffffff810d3c6f>] kthread+0xdf/0x100
      [ 2187.044287]  [<ffffffff810d3b90>] ? __init_kthread_worker+0x70/0x70
      [ 2187.044287]  [<ffffffff81d9873c>] ret_from_fork+0x7c/0xb0
      [ 2187.044287]  [<ffffffff810d3b90>] ? __init_kthread_worker+0x70/0x70
      [ 2187.044287] Code: 0f 1f 44 00 00 31 c0 5d c3 66 66 66 2e 0f 1f 84 00 00 00 00 00 55 48 8d b7 48 fe ff ff 48 8b 87 58 fe ff ff 48 89 e5 48 8b 40 30 <48> 8b 00 48 8b 10 48 89 c7 48 8b 92 90 03 00 00 ff 52 28 5d c3
      [ 2187.044287] RIP  [<ffffffff81361ca6>] free_lock_state_work+0x16/0x30
      [ 2187.044287]  RSP <ffff88007a4efd58>
      [ 2187.103626] ---[ end trace 0f11326d28e5d8fa ]---
      
      The original reason for this patch was because the fl_release_private
      operation couldn't sleep. With commit ed9814d8 (locks: defer freeing
      locks in locks_delete_lock until after i_lock has been dropped), this is
      no longer a problem so we can revert this patch.
      Reported-by: NChristoph Hellwig <hch@infradead.org>
      Signed-off-by: NJeff Layton <jlayton@primarydata.com>
      Reviewed-by: NChristoph Hellwig <hch@lst.de>
      Tested-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      0c0e0d3c
  20. 13 7月, 2014 3 次提交
    • J
      nfs4: turn free_lock_state into a void return operation · f1cdae87
      Jeff Layton 提交于
      Nothing checks its return value.
      Signed-off-by: NJeff Layton <jlayton@poochiereds.net>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      f1cdae87
    • J
      nfs4: queue free_lock_state job submission to nfsiod · 49a4bda2
      Jeff Layton 提交于
      We got a report of the following warning in Fedora:
      
      BUG: sleeping function called from invalid context at mm/slub.c:969
      in_atomic(): 1, irqs_disabled(): 0, pid: 533, name: bash
      3 locks held by bash/533:
       #0:  (&sp->so_delegreturn_mutex){+.+...}, at: [<ffffffffa033da62>] nfs4_proc_lock+0x262/0x910 [nfsv4]
       #1:  (&nfsi->rwsem){.+.+.+}, at: [<ffffffffa033da6a>] nfs4_proc_lock+0x26a/0x910 [nfsv4]
       #2:  (&sb->s_type->i_lock_key#23){+.+...}, at: [<ffffffff812998dc>] flock_lock_file_wait+0x8c/0x3a0
      CPU: 0 PID: 533 Comm: bash Not tainted 3.15.0-0.rc1.git1.1.fc21.x86_64 #1
      Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
       0000000000000000 00000000d664ff3c ffff880078b69a70 ffffffff817e82e0
       0000000000000000 ffff880078b69a98 ffffffff810cf1a4 0000000000000050
       0000000000000050 ffff88007cc01a00 ffff880078b69ad8 ffffffff8121449e
      Call Trace:
       [<ffffffff817e82e0>] dump_stack+0x4d/0x66
       [<ffffffff810cf1a4>] __might_sleep+0x184/0x240
       [<ffffffff8121449e>] kmem_cache_alloc_trace+0x4e/0x330
       [<ffffffffa0331124>] ? nfs4_release_lockowner+0x74/0x110 [nfsv4]
       [<ffffffffa0331124>] nfs4_release_lockowner+0x74/0x110 [nfsv4]
       [<ffffffffa0352340>] nfs4_put_lock_state+0x90/0xb0 [nfsv4]
       [<ffffffffa0352375>] nfs4_fl_release_lock+0x15/0x20 [nfsv4]
       [<ffffffff81297515>] locks_free_lock+0x45/0x90
       [<ffffffff8129996c>] flock_lock_file_wait+0x11c/0x3a0
       [<ffffffffa033da6a>] ? nfs4_proc_lock+0x26a/0x910 [nfsv4]
       [<ffffffffa033301e>] do_vfs_lock+0x1e/0x30 [nfsv4]
       [<ffffffffa033da79>] nfs4_proc_lock+0x279/0x910 [nfsv4]
       [<ffffffff810dbb26>] ? local_clock+0x16/0x30
       [<ffffffff810f5a3f>] ? lock_release_holdtime.part.28+0xf/0x200
       [<ffffffffa02f820c>] do_unlk+0x8c/0xc0 [nfs]
       [<ffffffffa02f85c5>] nfs_flock+0xa5/0xf0 [nfs]
       [<ffffffff8129a6f6>] locks_remove_file+0xb6/0x1e0
       [<ffffffff812159d8>] ? kfree+0xd8/0x2d0
       [<ffffffff8123bc63>] __fput+0xd3/0x210
       [<ffffffff8123bdee>] ____fput+0xe/0x10
       [<ffffffff810bfb6d>] task_work_run+0xcd/0xf0
       [<ffffffff81019cd1>] do_notify_resume+0x61/0x90
       [<ffffffff817fbea2>] int_signal+0x12/0x17
      
      The problem is that NFSv4 is trying to do an allocation from
      fl_release_private (in order to send a RELEASE_LOCKOWNER call). That
      function can be called while holding the inode->i_lock, and it's
      currently set up to do __GFP_WAIT allocations. v4.1 code has a
      similar problem.
      
      This patch adds a work_struct to the nfs4_lock_state and has the code
      queue the free_lock_state operation to nfsiod.
      Reported-by: NJosh Stone <jistone@redhat.com>
      Signed-off-by: NJeff Layton <jlayton@poochiereds.net>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      49a4bda2
    • J
      nfs4: treat lock owners as opaque values · 8003d3c4
      Jeff Layton 提交于
      Do the following set of ops with a file on a NFSv4 mount:
      
          exec 3>>/file/on/nfsv4
          flock -x 3
          exec 3>&-
      
      You'll see the LOCK request go across the wire, but no LOCKU when the
      file is closed.
      
      What happens is that the fd is passed across a fork, and the final close
      is done in a different process than the opener. That makes
      __nfs4_find_lock_state miss finding the correct lock state because it
      uses the fl_pid as a search key. A new one is created, and the locking
      code treats it as a delegation stateid (because NFS_LOCK_INITIALIZED
      isn't set).
      
      The root cause of this breakage seems to be commit 77041ed9
      (NFSv4: Ensure the lockowners are labelled using the fl_owner and/or
      fl_pid).
      
      That changed it so that flock lockowners are allocated based on the
      fl_pid. I think this is incorrect. flock locks should be "owned" by the
      struct file, and that is already accounted for in the fl_owner field of
      the lock request when it comes through nfs_flock.
      
      This patch basically reverts the above commit and with it, a LOCKU is
      sent in the above reproducer.
      Signed-off-by: NJeff Layton <jlayton@poochiereds.net>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      8003d3c4
  21. 25 6月, 2014 2 次提交
  22. 29 5月, 2014 1 次提交
  23. 20 2月, 2014 2 次提交
  24. 30 1月, 2014 1 次提交
  25. 20 11月, 2013 1 次提交
  26. 29 10月, 2013 5 次提交
    • W
      NFSv4: make nfs_find_best_sec static · 47fd88e6
      Weston Andros Adamson 提交于
      It's not used outside of nfs4namespace.c anymore.
      Signed-off-by: NWeston Andros Adamson <dros@netapp.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      47fd88e6
    • C
      NFS: Support NFS4ERR_LEASE_MOVED recovery in state manager · b7f7a66e
      Chuck Lever 提交于
      A migration on the FSID in play for the current NFS operation
      is reported via the error status code NFS4ERR_MOVED.
      
      "Lease moved" means that a migration has occurred on some other
      FSID than the one for the current operation.  It's a signal that
      the client should take action immediately to handle a migration
      that it may not have noticed otherwise.  This is so that the
      client's lease does not expire unnoticed on the destination server.
      
      In NFSv4.0, a moved lease is reported with the NFS4ERR_LEASE_MOVED
      error status code.
      
      To recover from NFS4ERR_LEASE_MOVED, check each FSID for that server
      to see if it is still present.  Invoke nfs4_try_migration() if the
      FSID is no longer present on the server.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      b7f7a66e
    • C
      NFS: Add method to detect whether an FSID is still on the server · 44c99933
      Chuck Lever 提交于
      Introduce a mechanism for probing a server to determine if an FSID
      is present or absent.
      
      The on-the-wire compound is different between minor version 0 and 1.
      Minor version 0 appends a RENEW operation to identify which client
      ID is probing.  Minor version 1 has a SEQUENCE operation in the
      compound which effectively carries the same information.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      44c99933
    • C
      NFS: Add basic migration support to state manager thread · c9fdeb28
      Chuck Lever 提交于
      Migration recovery and state recovery must be serialized, so handle
      both in the state manager thread.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      c9fdeb28
    • C
      NFS: Add method to retrieve fs_locations during migration recovery · b03d735b
      Chuck Lever 提交于
      The nfs4_proc_fs_locations() function is invoked during referral
      processing to perform a GETATTR(fs_locations) on an object's parent
      directory in order to discover the target of the referral.  It
      performs a LOOKUP in the compound, so the client needs to know the
      parent's file handle a priori.
      
      Unfortunately this function is not adequate for handling migration
      recovery.  We need to probe fs_locations information on an FSID, but
      there's no parent directory available for many operations that
      can return NFS4ERR_MOVED.
      
      Another subtlety: recovering from NFS4ERR_LEASE_MOVED is a process
      of walking over a list of known FSIDs that reside on the server, and
      probing whether they have migrated.  Once the server has detected
      that the client has probed all migrated file systems, it stops
      returning NFS4ERR_LEASE_MOVED.
      
      A minor version zero server needs to know what client ID is
      requesting fs_locations information so it can clear the flag that
      forces it to continue returning NFS4ERR_LEASE_MOVED.  This flag is
      set per client ID and per FSID.  However, the client ID is not an
      argument of either the PUTFH or GETATTR operations.  Later minor
      versions have client ID information embedded in the compound's
      SEQUENCE operation.
      
      Therefore, by convention, minor version zero clients send a RENEW
      operation in the same compound as the GETATTR(fs_locations), since
      RENEW's one argument is a clientid4.  This allows a minor version
      zero server to identify correctly the client that is probing for a
      migration.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      b03d735b