linux-stable.git/net/sunrpc, branch v4.20.2

xprtrdma: Yet another double DMA-unmap

2019-01-13T08:24:07+00:00

commit e2f34e26710bfaa545a9d9cd0c70137406401467 upstream.

While chasing yet another set of DMAR fault reports, I noticed that
the frwr recycler conflates whether or not an MR has been DMA
unmapped with frwr->fr_state. Actually the two have only an indirect
relationship. It's in fact impossible to guess reliably whether the
MR has been DMA unmapped based on its fr_state field, especially as
the surrounding code and its assumptions have changed over time.

A better approach is to track the DMA mapping status explicitly so
that the recycler is less brittle to unexpected situations, and
attempts to DMA-unmap a second time are prevented.

Signed-off-by: Chuck Lever 
Cc: stable@vger.kernel.org # v4.20
Signed-off-by: Anna Schumaker 
Signed-off-by: Greg Kroah-Hartman

sunrpc: use SVC_NET() in svcauth_gss_* functions

2019-01-13T08:24:03+00:00

commit b8be5674fa9a6f3677865ea93f7803c4212f3e10 upstream.

Signed-off-by: Vasily Averin 
Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

sunrpc: fix cache_head leak due to queued request

2019-01-13T08:24:03+00:00

commit 4ecd55ea074217473f94cfee21bb72864d39f8d7 upstream.

After commit d202cce8963d, an expired cache_head can be removed from the
cache_detail's hash.

However, the expired cache_head may be waiting for a reply from a
previously submitted request. Such a cache_head has an increased
refcounter and therefore it won't be freed after cache_put(freeme).

Because the cache_head was removed from the hash it cannot be found
during cache_clean() and can be leaked forever, together with stalled
cache_request and other taken resources.

In our case we noticed it because an entry in the export cache was
holding a reference on a filesystem.

Fixes d202cce8963d ("sunrpc: never return expired entries in sunrpc_cache_lookup")
Cc: Pavel Tikhomirov 
Cc: stable@kernel.org # 2.6.35
Signed-off-by: Vasily Averin 
Reviewed-by: NeilBrown 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

sock: Make sock->sk_stamp thread-safe

2019-01-09T16:45:51+00:00

[ Upstream commit 3a0ed3e9619738067214871e9cb826fa23b2ddb9 ]

Al Viro mentioned (Message-ID
<20170626041334.GZ10672@ZenIV.linux.org.uk>)
that there is probably a race condition
lurking in accesses of sk_stamp on 32-bit machines.

sock->sk_stamp is of type ktime_t which is always an s64.
On a 32 bit architecture, we might run into situations of
unsafe access as the access to the field becomes non atomic.

Use seqlocks for synchronization.
This allows us to avoid using spinlocks for readers as
readers do not need mutual exclusion.

Another approach to solve this is to require sk_lock for all
modifications of the timestamps. The current approach allows
for timestamps to have their own lock: sk_stamp_lock.
This allows for the patch to not compete with already
existing critical sections, and side effects are limited
to the paths in the patch.

The addition of the new field maintains the data locality
optimizations from
commit 9115e8cd2a0c ("net: reorganize struct sock for better data
locality")

Note that all the instances of the sk_stamp accesses
are either through the ioctl or the syscall recvmsg.

Signed-off-by: Deepa Dinamani 
Signed-off-by: David S. Miller 
Signed-off-by: Greg Kroah-Hartman

SUNRPC: Remove xprt_connect_status()

2018-12-18T16:04:10+00:00

Over the years, xprt_connect_status() has been superseded by
call_connect_status(), which now handles all the errors that
xprt_connect_status() does and more. Since the latter converts
all errors that it doesn't recognise to EIO, then it is time
for it to be retired.

Reported-by: Chuck Lever 
Signed-off-by: Trond Myklebust 
Tested-by: Chuck Lever

SUNRPC: Fix a race with XPRT_CONNECTING

2018-12-18T16:04:03+00:00

Ensure that we clear XPRT_CONNECTING before releasing the XPRT_LOCK so that
we don't have races between the (asynchronous) socket setup code and
tasks in xprt_connect().

Signed-off-by: Trond Myklebust 
Tested-by: Chuck Lever

SUNRPC: Fix disconnection races

2018-12-18T16:03:57+00:00

When the socket is closed, we need to call xprt_disconnect_done() in order
to clean up the XPRT_WRITE_SPACE flag, and wake up the sleeping tasks.

However, we also want to ensure that we don't wake them up before the socket
is closed, since that would cause thundering herd issues with everyone
piling up to retransmit before the TCP shutdown dance has completed.
Only the task that holds XPRT_LOCKED needs to wake up early in order to
allow the close to complete.

Reported-by: Dave Wysochanski 
Reported-by: Scott Mayhew 
Cc: Chuck Lever 
Signed-off-by: Trond Myklebust 
Tested-by: Chuck Lever

SUNRPC: Don't force a redundant disconnection in xs_read_stream()

2018-12-05T12:11:12+00:00

If the connection is broken, then xs_tcp_state_change() will take care
of scheduling the socket close as soon as appropriate. xs_read_stream()
just needs to report the error.

Signed-off-by: Trond Myklebust

SUNRPC: Fix up socket polling

2018-12-05T12:11:12+00:00

Ensure that we do not exit the socket read callback without clearing
XPRT_SOCK_DATA_READY.

Signed-off-by: Trond Myklebust

SUNRPC: Use the discard iterator rather than MSG_TRUNC

2018-12-05T12:11:12+00:00

When discarding message data from the stream, we're better off using
the discard iterator, since that will work with non-TCP streams.

Signed-off-by: Trond Myklebust