Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 15 5月, 2017 1 次提交
  3. 28 4月, 2017 2 次提交
  5. 02 3月, 2017 1 次提交
  7. 28 2月, 2017 1 次提交
  9. 25 2月, 2017 3 次提交
  11. 01 12月, 2016 1 次提交
    • C
      svcauth_gss: Close connection when dropping an incoming message · 4d712ef1
      由 Chuck Lever 提交于 
      S5.3.3.1 of RFC 2203 requires that an incoming GSS-wrapped message
whose sequence number lies outside the current window is dropped.
The rationale is:

  The reason for discarding requests silently is that the server
  is unable to determine if the duplicate or out of range request
  was due to a sequencing problem in the client, network, or the
  operating system, or due to some quirk in routing, or a replay
  attack by an intruder.  Discarding the request allows the client
  to recover after timing out, if indeed the duplication was
  unintentional or well intended.

However, clients may rely on the server dropping the connection to
indicate that a retransmit is needed. Without a connection reset, a
client can wait forever without retransmitting, and the workload
just stops dead. I've reproduced this behavior by running xfstests
generic/323 on an NFSv4.0 mount with proto=rdma and sec=krb5i.

To address this issue, have the server close the connection when it
silently discards an incoming message due to a GSS sequence number
problem.

There are a few other places where the server will never reply.
Change those spots in a similar fashion.
Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      4d712ef1
  13. 20 9月, 2016 1 次提交
  15. 12 7月, 2016 2 次提交
  17. 08 12月, 2015 1 次提交
    • T
      SUNRPC: Fix callback channel · 756b9b37
      由 Trond Myklebust 提交于 
      The NFSv4.1 callback channel is currently broken because the receive
message will keep shrinking because the backchannel receive buffer size
never gets reset.
The easiest solution to this problem is instead of changing the receive
buffer, to rather adjust the copied request.

Fixes: 38b7631f ("nfs4: limit callback decoding to received bytes")
Cc: Benjamin Coddington <bcodding@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      756b9b37
  19. 24 11月, 2015 1 次提交
    • B
      nfs4: limit callback decoding to received bytes · 38b7631f
      由 Benjamin Coddington 提交于 
      A truncated cb_compound request will cause the client to decode null or
data from a previous callback for nfs4.1 backchannel case, or uninitialized
data for the nfs4.0 case. This is because the path through
svc_process_common() advances the request's iov_base and decrements iov_len
without adjusting the overall xdr_buf's len field.  That causes
xdr_init_decode() to set up the xdr_stream with an incorrect length in
nfs4_callback_compound().

Fixing this for the nfs4.1 backchannel case first requires setting the
correct iov_len and page_len based on the length of received data in the
same manner as the nfs4.0 case.

Then the request's xdr_buf length can be adjusted for both cases based upon
the remaining iov_len and page_len.
Signed-off-by: NBenjamin Coddington <bcodding@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: NTrond Myklebust <trond.myklebust@primarydata.com>
      38b7631f
  21. 03 11月, 2015 1 次提交
  23. 11 8月, 2015 5 次提交
  25. 05 6月, 2015 2 次提交
  27. 04 6月, 2015 1 次提交
  29. 03 6月, 2015 1 次提交
  31. 23 1月, 2015 1 次提交
  33. 10 12月, 2014 6 次提交
  35. 02 12月, 2014 1 次提交
  37. 25 11月, 2014 2 次提交
  39. 29 10月, 2014 1 次提交
  41. 18 8月, 2014 1 次提交
  43. 23 6月, 2014 1 次提交
  45. 04 1月, 2014 1 次提交
  47. 14 11月, 2013 1 次提交
  49. 04 7月, 2013 1 次提交