1. 28 Jul, 2015 1 commit
  2. 27 Jul, 2015 5 commits
    • Trond Myklebust's avatar
    • NeilBrown's avatar
      sunrpc: translate -EAGAIN to -ENOBUFS when socket is writable. · 743c69e7
      NeilBrown authored
      The networking layer does not reliably report the distinction between
      a non-block write failing because:
       1/ the queue is too full already and
       2/ a memory allocation attempt failed.
      
      The distinction is important because in the first case it is
      appropriate to retry as soon as the socket reports that it is
      writable, and in the second case a small delay is required as the
      socket will most likely report as writable but kmalloc could still
      fail.
      
      sk_stream_wait_memory() exhibits this distinction nicely, setting
      'vm_wait' if a small wait is needed.  However in the non-blocking case
      it always returns -EAGAIN no matter the cause of the failure.  This
      -EAGAIN call get all the way to sunrpc.
      
      The sunrpc layer expects EAGAIN to indicate the first cause, and
      ENOBUFS to indicate the second.  Various documentation suggests that
      this is not unreasonable, but does not guarantee the desired error
      codes.
      
      The result of getting -EAGAIN when -ENOBUFS is expected is that the
      send is tried again in a tight loop and soft lockups are reported.
      
      so: add tests after calls to xs_sendpages() to translate -EAGAIN into
      -ENOBUFS if the socket is writable.  This cannot happen inside
      xs_sendpages() as the test for "is socket writable" is different
      between TCP and UDP.
      
      With this change, the tight loop retrying xs_sendpages() becomes a
      loop which only retries every 250ms, and so will not trigger a
      soft-lockup warning.
      
      It is possible that the write did fail because the queue was too full
      and by the time xs_sendpages() completed, the queue was writable
      again.  In this case an extra 250ms delay is inserted that isn't
      really needed.  This circumstance suggests a degree of congestion so a
      delay is not necessarily a bad thing, and it can only cause a single
      250ms delay, not a series of them.
      Signed-off-by: default avatarNeilBrown <neilb@suse.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      743c69e7
    • J. Bruce Fields's avatar
      NFSv4.2: handle NFS-specific llseek errors · bdcc2cd1
      J. Bruce Fields authored
      Handle NFS-specific llseek errors instead of letting them leak out to
      userspace.
      Reported-by: default avatarBenjamin Coddington <bcodding@redhat.com>
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      bdcc2cd1
    • Trond Myklebust's avatar
      NFS: Don't clear desc->pg_moreio in nfs_do_recoalesce() · d4c30454
      Trond Myklebust authored
      Recoalescing does not affect whether or not we've already sent off
      I/O, and doing so means that we end up sending a bunch of synchronous
      for cases where we actually need to be using unstable writes.
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      d4c30454
    • Trond Myklebust's avatar
      NFS: Fix a memory leak in nfs_do_recoalesce · 03d5eb65
      Trond Myklebust authored
      If the function exits early, then we must put those requests that were
      not processed back onto the &mirror->pg_list so they can be cleaned up
      by nfs_pgio_error().
      
      Fixes: a7d42ddb ("nfs: add mirroring support to pgio layer")
      Cc: stable@vger.kernel.org # v4.0+
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      03d5eb65
  3. 22 Jul, 2015 8 commits
  4. 11 Jul, 2015 5 commits
  5. 08 Jul, 2015 1 commit
  6. 05 Jul, 2015 5 commits
  7. 03 Jul, 2015 2 commits
  8. 01 Jul, 2015 9 commits
  9. 29 Jun, 2015 1 commit
    • NeilBrown's avatar
      NFSv4: When returning a delegation, don't reclaim an incompatible open mode. · 39f897fd
      NeilBrown authored
      It is possible to have an active open with one mode, and a delegation
      for the same file with a different mode.
      In particular, a WR_ONLY open and an RD_ONLY delegation.
      This happens if a WR_ONLY open is followed by a RD_ONLY open which
      provides a delegation, but is then close.
      
      When returning the delegation, we currently try to claim opens for
      every open type (n_rdwr, n_rdonly, n_wronly).  As there is no harm
      in claiming an open for a mode that we already have, this is often
      simplest.
      
      However if the delegation only provides a subset of the modes that we
      currently have open, this will produce an error from the server.
      
      So when claiming open modes prior to returning a delegation, skip the
      open request if the mode is not covered by the delegation - the open_stateid
      must already cover that mode, so there is nothing to do.
      Signed-off-by: default avatarNeilBrown <neilb@suse.de>
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      39f897fd
  10. 27 Jun, 2015 2 commits
  11. 26 Jun, 2015 1 commit