1. 21 4月, 2017 2 次提交
  2. 02 12月, 2016 1 次提交
  3. 23 9月, 2016 2 次提交
    • J
      nfs: allow blocking locks to be awoken by lock callbacks · a1d617d8
      Jeff Layton 提交于
      Add a waitqueue head to the client structure. Have clients set a wait
      on that queue prior to requesting a lock from the server. If the lock
      is blocked, then we can use that to wait for wakeups.
      
      Note that we do need to do this "manually" since we need to set the
      wait on the waitqueue prior to requesting the lock, but requesting a
      lock can involve activities that can block.
      
      However, only do that for NFSv4.1 locks, either by compiling out
      all of the waitqueue handling when CONFIG_NFS_V4_1 is disabled, or
      skipping all of it at runtime if we're dealing with v4.0, or v4.1
      servers that don't send lock callbacks.
      
      Note too that even when we expect to get a lock callback, RFC5661
      section 20.11.4 is pretty clear that we still need to poll for them,
      so we do still sleep on a timeout. We do however always poll at the
      longest interval in that case.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      [Anna: nfs4_retry_setlk() "status" should default to -ERESTARTSYS]
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      a1d617d8
    • J
      nfs: add handling for CB_NOTIFY_LOCK in client · db783688
      Jeff Layton 提交于
      For now, the callback doesn't do anything. Support for that will be
      added in later patches.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      db783688
  4. 29 8月, 2016 3 次提交
  5. 25 7月, 2016 2 次提交
    • T
      pNFS: Remove redundant pnfs_mark_layout_returned_if_empty() · f71dfe8f
      Trond Myklebust 提交于
      That's already being taken care of in pnfs_layout_remove_lseg().
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      f71dfe8f
    • T
      pNFS: Fix CB_LAYOUTRECALL stateid verification · 793b7fe5
      Trond Myklebust 提交于
      We want to evaluate in this order:
      
      If the client holds no layout for this inode, then return
      NFS4ERR_NOMATCHING_LAYOUT; it probably forgot the layout.
      
      If the client finds the inode among the list of layouts, but the corresponding
      stateid has not yet been initialised, then return NFS4ERR_DELAY to ask the
      server to retry once the outstanding LAYOUTGET is complete.
      
      If the current layout stateid's "other" field does not match the recalled
      stateid, return NFS4ERR_BAD_STATEID.
      
      If already processing a layout recall with a newer stateid, return
      NFS4ERR_OLD_STATEID. This can only happens for servers that are
      non-compliant with the NFSv4.1 protocol.
      
      If already processing a layout recall with an older stateid, return
      NFS4ERR_DELAY to ask the server to retry once the outstanding
      LAYOUTRETURN is complete. Again, this is technically incompliant with
      the NFSv4.1 protocol.
      
      If the current layout sequence id is newer than the recalled stateid's
      sequence id, return NFS4ERR_OLD_STATEID. This too implies protocol
      non-compliance.
      
      If the current layout sequence id is older than the recalled stateid's
      sequence id+1, return NFS4ERR_DELAY.
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      793b7fe5
  6. 18 5月, 2016 2 次提交
    • J
      pnfs: only tear down lsegs that precede seqid in LAYOUTRETURN args · 6d597e17
      Jeff Layton 提交于
      LAYOUTRETURN is "special" in that servers and clients are expected to
      work with old stateids. When the client sends a LAYOUTRETURN with an old
      stateid in it then the server is expected to only tear down layout
      segments that were present when that seqid was current. Ensure that the
      client handles its accounting accordingly.
      Signed-off-by: NJeff Layton <jeff.layton@primarydata.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      6d597e17
    • O
      Fixing oops in callback path · c2985d00
      Olga Kornievskaia 提交于
      Commit 80f96427 ("NFSv4.x: Enforce the ca_maxreponsesize_cached
      on the back channel") causes an oops when it receives a callback with
      cachethis=yes.
      
      [  109.667378] BUG: unable to handle kernel NULL pointer dereference at 00000000000002c8
      [  109.669476] IP: [<ffffffffa08a3e68>] nfs4_callback_compound+0x4f8/0x690 [nfsv4]
      [  109.671216] PGD 0
      [  109.671736] Oops: 0000 [#1] SMP
      [  109.705427] CPU: 1 PID: 3579 Comm: nfsv4.1-svc Not tainted 4.5.0-rc1+ #1
      [  109.706987] Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/20/2014
      [  109.709468] task: ffff8800b4408000 ti: ffff88008448c000 task.ti: ffff88008448c000
      [  109.711207] RIP: 0010:[<ffffffffa08a3e68>]  [<ffffffffa08a3e68>] nfs4_callback_compound+0x4f8/0x690 [nfsv4]
      [  109.713521] RSP: 0018:ffff88008448fca0  EFLAGS: 00010286
      [  109.714762] RAX: ffff880081ee202c RBX: ffff8800b7b5b600 RCX: 0000000000000001
      [  109.716427] RDX: 0000000000000008 RSI: 0000000000000008 RDI: 0000000000000000
      [  109.718091] RBP: ffff88008448fda8 R08: 0000000000000000 R09: 000000000b000000
      [  109.719757] R10: ffff880137786000 R11: ffff8800b7b5b600 R12: 0000000001000000
      [  109.721415] R13: 0000000000000002 R14: 0000000053270000 R15: 000000000000000b
      [  109.723061] FS:  0000000000000000(0000) GS:ffff880139640000(0000) knlGS:0000000000000000
      [  109.724931] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [  109.726278] CR2: 00000000000002c8 CR3: 0000000034d50000 CR4: 00000000001406e0
      [  109.727972] Stack:
      [  109.728465]  ffff880081ee202c ffff880081ee201c 000000008448fcc0 ffff8800baccb800
      [  109.730349]  ffff8800baccc800 ffffffffa08d0380 0000000000000000 0000000000000000
      [  109.732211]  ffff8800b7b5b600 0000000000000001 ffffffff81d073c0 ffff880081ee3090
      [  109.734056] Call Trace:
      [  109.734657]  [<ffffffffa03795d4>] svc_process_common+0x5c4/0x6c0 [sunrpc]
      [  109.736267]  [<ffffffffa0379a4c>] bc_svc_process+0x1fc/0x360 [sunrpc]
      [  109.737775]  [<ffffffffa08a2c2c>] nfs41_callback_svc+0x10c/0x1d0 [nfsv4]
      [  109.739335]  [<ffffffff810cb380>] ? prepare_to_wait_event+0xf0/0xf0
      [  109.740799]  [<ffffffffa08a2b20>] ? nfs4_callback_svc+0x50/0x50 [nfsv4]
      [  109.742349]  [<ffffffff810a6998>] kthread+0xd8/0xf0
      [  109.743495]  [<ffffffff810a68c0>] ? kthread_park+0x60/0x60
      [  109.744776]  [<ffffffff816abc4f>] ret_from_fork+0x3f/0x70
      [  109.746037]  [<ffffffff810a68c0>] ? kthread_park+0x60/0x60
      [  109.747324] Code: cc 45 31 f6 48 8b 85 00 ff ff ff 44 89 30 48 8b 85 f8 fe ff ff 44 89 20 48 8b 9d 38 ff ff ff 48 8b bd 30 ff ff ff 48 85 db 74 4c <4c> 8b af c8 02 00 00 4d 8d a5 08 02 00 00 49 81 c5 98 02 00 00
      [  109.754361] RIP  [<ffffffffa08a3e68>] nfs4_callback_compound+0x4f8/0x690 [nfsv4]
      [  109.756123]  RSP <ffff88008448fca0>
      [  109.756951] CR2: 00000000000002c8
      [  109.757738] ---[ end trace 2b8555511ab5dfb4 ]---
      [  109.758819] Kernel panic - not syncing: Fatal exception
      [  109.760126] Kernel Offset: disabled
      [  118.938934] ---[ end Kernel panic - not syncing: Fatal exception
      
      It doesn't unlock the table nor does it set the cps->clp pointer which
      is later needed by nfs4_cb_free_slot().
      
      Fixes: 80f96427 ("NFSv4.x: Enforce the ca_maxresponsesize_cached ...")
      CC: stable@vger.kernel.org
      Signed-off-by: NOlga Kornievskaia <kolga@netapp.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      c2985d00
  7. 02 2月, 2016 1 次提交
  8. 25 1月, 2016 5 次提交
  9. 05 1月, 2016 1 次提交
  10. 01 1月, 2016 1 次提交
  11. 29 12月, 2015 5 次提交
  12. 22 10月, 2015 1 次提交
  13. 26 8月, 2015 2 次提交
  14. 18 8月, 2015 1 次提交
  15. 12 6月, 2015 3 次提交
  16. 19 2月, 2015 1 次提交
  17. 25 11月, 2014 1 次提交
    • W
      NFS: fix subtle change in COMMIT behavior · cb1410c7
      Weston Andros Adamson 提交于
      Recent work in the pgio layer made it possible for there to be more than one
      request per page. This caused a subtle change in commit behavior, because
      write.c:nfs_commit_unstable_pages compares the number of *pages* waiting for
      writeback against the number of requests on a commit list to choose when to
      send a COMMIT in a non-blocking flush.
      
      This is probably hard to hit in normal operation - you have to be using
      rsize/wsize < PAGE_SIZE, or pnfs with lots of boundaries that are not page
      aligned to have a noticeable change in behavior.
      Signed-off-by: NWeston Andros Adamson <dros@primarydata.com>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      cb1410c7
  18. 13 9月, 2014 1 次提交
    • C
      pnfs: enable CB_NOTIFY_DEVICEID support · 84c9dee3
      Christoph Hellwig 提交于
      This code has been around for a while, but never was enabled, although
      it is in a working shape.
      
      Note that we implement NOTIFY_DEVICEID4_CHANGE identical to
      NOTIFY_DEVICEID4_DELETE.  Given that in either case we can't do anything
      but preventing further lookups of a given device ID there isn't much difference
      in semantics for the two.  For the delete case the server MUST ensure that
      there are no outstanding layouts, while for the change case it doesn't, but
      that has little relevance to the client.
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      84c9dee3
  19. 11 9月, 2014 2 次提交
  20. 20 2月, 2014 2 次提交
  21. 04 9月, 2013 1 次提交