linux-stable.git/net/sunrpc, branch v3.4.22

SUNRPC: Prevent races in xs_abort_connection()

2012-10-31T17:02:57+00:00

commit 4bc1e68ed6a8b59be8a79eb719be515a55c7bc68 upstream.

The call to xprt_disconnect_done() that is triggered by a successful
connection reset will trigger another automatic wakeup of all tasks
on the xprt->pending rpc_wait_queue. In particular it will cause an
early wake up of the task that called xprt_connect().

All we really want to do here is clear all the socket-specific state
flags, so we split that functionality out of xs_sock_mark_closed()
into a helper that can be called by xs_abort_connection()

Reported-by: Chris Perl 
Signed-off-by: Trond Myklebust 
Tested-by: Chris Perl 
Signed-off-by: Greg Kroah-Hartman

Revert "SUNRPC: Ensure we close the socket on EPIPE errors too..."

2012-10-31T17:02:57+00:00

commit b9d2bb2ee537424a7f855e1f93eed44eb9ee0854 upstream.

This reverts commit 55420c24a0d4d1fce70ca713f84aa00b6b74a70e.
Now that we clear the connected flag when entering TCP_CLOSE_WAIT,
the deadlock described in this commit is no longer possible.
Instead, the resulting call to xs_tcp_shutdown() can interfere
with pending reconnection attempts.

Reported-by: Chris Perl 
Signed-off-by: Trond Myklebust 
Tested-by: Chris Perl 
Signed-off-by: Greg Kroah-Hartman

SUNRPC: Clear the connect flag when socket state is TCP_CLOSE_WAIT

2012-10-31T17:02:57+00:00

commit d0bea455dd48da1ecbd04fedf00eb89437455fdc upstream.

This is needed to ensure that we call xprt_connect() upon the next
call to call_connect().

Signed-off-by: Trond Myklebust 
Tested-by: Chris Perl 
Signed-off-by: Greg Kroah-Hartman

SUNRPC: Get rid of the xs_error_report socket callback

2012-10-31T17:02:56+00:00

commit f878b657ce8e7d3673afe48110ec208a29e38c4a upstream.

Chris Perl reports that we're seeing races between the wakeup call in
xs_error_report and the connect attempts. Basically, Chris has shown
that in certain circumstances, the call to xs_error_report causes the
rpc_task that is responsible for reconnecting to wake up early, thus
triggering a disconnect and retry.

Since the sk->sk_error_report() calls in the socket layer are always
followed by a tcp_done() in the cases where we care about waking up
the rpc_tasks, just let the state_change callbacks take responsibility
for those wake ups.

Reported-by: Chris Perl 
Signed-off-by: Trond Myklebust 
Tested-by: Chris Perl 
Signed-off-by: Greg Kroah-Hartman

SUNRPC: Fix a UDP transport regression

2012-10-28T17:14:13+00:00

commit f39c1bfb5a03e2d255451bff05be0d7255298fa4 and
commit 84e28a307e376f271505af65a7b7e212dd6f61f4 upstream.

Commit 43cedbf0e8dfb9c5610eb7985d5f21263e313802 (SUNRPC: Ensure that
we grab the XPRT_LOCK before calling xprt_alloc_slot) is causing
hangs in the case of NFS over UDP mounts.

Since neither the UDP or the RDMA transport mechanism use dynamic slot
allocation, we can skip grabbing the socket lock for those transports.
Add a new rpc_xprt_op to allow switching between the TCP and UDP/RDMA
case.

Note that the NFSv4.1 back channel assigns the slot directly
through rpc_run_bc_task, so we can ignore that case.

Reported-by: Dick Streefland 
Signed-off-by: Bryan Schumaker 
Signed-off-by: Trond Myklebust 
Signed-off-by: Greg Kroah-Hartman

SUNRPC: Prevent kernel stack corruption on long values of flush

2012-10-28T17:14:13+00:00

commit 212ba90696ab4884e2025b0b13726d67aadc2cd4 upstream.

The buffer size in read_flush() is too small for the longest possible values
for it. This can lead to a kernel stack corruption:

[   43.047329] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff833e64b4
[   43.047329]
[   43.049030] Pid: 6015, comm: trinity-child18 Tainted: G        W    3.5.0-rc7-next-20120716-sasha #221
[   43.050038] Call Trace:
[   43.050435]  [] panic+0xcd/0x1f4
[   43.050931]  [] ? read_flush.isra.7+0xe4/0x100
[   43.051602]  [] __stack_chk_fail+0x16/0x20
[   43.052206]  [] read_flush.isra.7+0xe4/0x100
[   43.052951]  [] ? read_flush_pipefs+0x30/0x30
[   43.053594]  [] read_flush_procfs+0x2c/0x30
[   43.053596]  [] proc_reg_read+0x9c/0xd0
[   43.053596]  [] ? proc_reg_write+0xd0/0xd0
[   43.053596]  [] do_loop_readv_writev+0x4b/0x90
[   43.053596]  [] do_readv_writev+0xf6/0x1d0
[   43.053596]  [] vfs_readv+0x3e/0x60
[   43.053596]  [] sys_readv+0x48/0xb0
[   43.053596]  [] system_call_fastpath+0x1a/0x1f

Signed-off-by: Sasha Levin 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

SUNRPC: Ensure that the TCP socket is closed when in CLOSE_WAIT

2012-10-21T16:27:58+00:00

commit a519fc7a70d1a918574bb826cc6905b87b482eb9 upstream.

Instead of doing a shutdown() call, we need to do an actual close().
Ditto if/when the server is sending us junk RPC headers.

Signed-off-by: Trond Myklebust 
Tested-by: Simon Kirby 
Signed-off-by: Greg Kroah-Hartman

svcrpc: sends on closed socket should stop immediately

2012-09-14T17:00:19+00:00

commit f06f00a24d76e168ecb38d352126fd203937b601 upstream.

svc_tcp_sendto sets XPT_CLOSE if we fail to transmit the entire reply.
However, the XPT_CLOSE won't be acted on immediately.  Meanwhile other
threads could send further replies before the socket is really shut
down.  This can manifest as data corruption: for example, if a truncated
read reply is followed by another rpc reply, that second reply will look
to the client like further read data.

Symptoms were data corruption preceded by svc_tcp_sendto logging
something like

	kernel: rpc-srv/tcp: nfsd: sent only 963696 when sending 1048708 bytes - shutting down socket

Reported-by: Malahal Naineni 
Tested-by: Malahal Naineni 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

svcrpc: fix svc_xprt_enqueue/svc_recv busy-looping

2012-09-14T17:00:19+00:00

commit d10f27a750312ed5638c876e4bd6aa83664cccd8 upstream.

The rpc server tries to ensure that there will be room to send a reply
before it receives a request.

It does this by tracking, in xpt_reserved, an upper bound on the total
size of the replies that is has already committed to for the socket.

Currently it is adding in the estimate for a new reply *before* it
checks whether there is space available.  If it finds that there is not
space, it then subtracts the estimate back out.

This may lead the subsequent svc_xprt_enqueue to decide that there is
space after all.

The results is a svc_recv() that will repeatedly return -EAGAIN, causing
server threads to loop without doing any actual work.

Reported-by: Michael Tokarev 
Tested-by: Michael Tokarev 
Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman

svcrpc: fix BUG() in svc_tcp_clear_pages

2012-09-14T17:00:19+00:00

commit be1e44441a560c43c136a562d49a1c9623c91197 upstream.

Examination of svc_tcp_clear_pages shows that it assumes sk_tcplen is
consistent with sk_pages[] (in particular, sk_pages[n] can't be NULL if
sk_tcplen would lead us to expect n pages of data).

svc_tcp_restore_pages zeroes out sk_pages[] while leaving sk_tcplen.
This is OK, since both functions are serialized by XPT_BUSY.  However,
that means the inconsistency must be repaired before dropping XPT_BUSY.

Therefore we should be ensuring that svc_tcp_save_pages repairs the
problem before exiting svc_tcp_recv_record on error.

Symptoms were a BUG() in svc_tcp_clear_pages.

Signed-off-by: J. Bruce Fields 
Signed-off-by: Greg Kroah-Hartman