1. 18 11月, 2017 1 次提交
    • T
      NFSv4.1: Fix up replays of interrupted requests · 3be0f80b
      Trond Myklebust 提交于
      If the previous request on a slot was interrupted before it was
      processed by the server, then our slot sequence number may be out of whack,
      and so we try the next operation using the old sequence number.
      
      The problem with this, is that not all servers check to see that the
      client is replaying the same operations as previously when they decide
      to go to the replay cache, and so instead of the expected error of
      NFS4ERR_SEQ_FALSE_RETRY, we get a replay of the old reply, which could
      (if the operations match up) be mistaken by the client for a new reply.
      
      To fix this, we attempt to send a COMPOUND containing only the SEQUENCE op
      in order to resync our slot sequence number.
      
      Cc: Olga Kornievskaia <olga.kornievskaia@gmail.com>
      [olga.kornievskaia@gmail.com: fix an Oops]
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      3be0f80b
  2. 21 8月, 2017 1 次提交
    • N
      NFSv4.1: don't use machine credentials for CLOSE when using 'sec=sys' · b79e87e0
      NeilBrown 提交于
      An NFSv4.1 client might close a file after the user who opened it has
      logged off.  In this case the user's credentials may no longer be
      valid, if they are e.g. kerberos credentials that have expired.
      
      NFSv4.1 has a mechanism to allow the client to use machine credentials
      to close a file.  However due to a short-coming in the RFC, a CLOSE
      with those credentials may not be possible if the file in question
      isn't exported to the same security flavor - the required PUTFH must
      be rejected when this is the case.
      
      Specifically if a server and client support kerberos in general and
      have used it to form a machine credential, but the file is only
      exported to "sec=sys", a PUTFH with the machine credentials will fail,
      so CLOSE is not possible.
      
      As RPC_AUTH_UNIX (used by sec=sys) credentials can never expire, there
      is no value in using the machine credential in place of them.
      So in that case, just use the users credentials for CLOSE etc, as you would
      in NFSv4.0
      Signed-off-by: NNeil Brown <neilb@suse.com>
      Signed-off-by: NNeilBrown <neilb@suse.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      b79e87e0
  3. 14 7月, 2017 2 次提交
  4. 15 5月, 2017 2 次提交
  5. 31 1月, 2017 2 次提交
  6. 02 12月, 2016 1 次提交
  7. 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
  8. 28 9月, 2016 2 次提交
  9. 23 9月, 2016 1 次提交
  10. 20 9月, 2016 3 次提交
  11. 06 8月, 2016 1 次提交
  12. 21 7月, 2016 1 次提交
  13. 01 7月, 2016 1 次提交
  14. 18 5月, 2016 2 次提交
  15. 08 10月, 2015 1 次提交
  16. 18 8月, 2015 1 次提交
  17. 24 6月, 2015 1 次提交
  18. 04 2月, 2015 2 次提交
  19. 24 1月, 2015 1 次提交
  20. 26 11月, 2014 1 次提交
  21. 01 10月, 2014 1 次提交
  22. 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
  23. 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
  24. 25 6月, 2014 2 次提交
  25. 29 5月, 2014 1 次提交
  26. 20 2月, 2014 2 次提交
  27. 30 1月, 2014 1 次提交
  28. 20 11月, 2013 1 次提交