Skip to content

L
linux
Switch branch/tag
  1. 28 Jul, 2015 1 commit
  3. 27 Jul, 2015 5 commits
    • Trond Myklebust's avatar
      SUNRPC: Report TCP errors to the caller · f580dd04
      Trond Myklebust authored 
      Signed-off-by: default avatarTrond Myklebust <trond.myklebust@primarydata.com>
      f580dd04
    • 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
  5. 22 Jul, 2015 8 commits
  7. 11 Jul, 2015 5 commits
  9. 08 Jul, 2015 1 commit
  11. 05 Jul, 2015 5 commits
  13. 03 Jul, 2015 2 commits
  15. 01 Jul, 2015 9 commits
  17. 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
  19. 27 Jun, 2015 2 commits
  21. 26 Jun, 2015 1 commit
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7