This is a note to let you know that I've just added the patch titled
rxrpc: Ignore BUSY packets on old calls
to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git%3Ba=su...
The filename of the patch is: rxrpc-ignore-busy-packets-on-old-calls.patch and it can be found in the queue-4.9 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree, please let stable@vger.kernel.org know about it.
From foo@baz Mon Dec 18 14:12:34 CET 2017
From: David Howells dhowells@redhat.com Date: Thu, 16 Mar 2017 16:27:10 +0000 Subject: rxrpc: Ignore BUSY packets on old calls
From: David Howells dhowells@redhat.com
[ Upstream commit 4d4a6ac73e7466c2085c307fac41f74ce4568a45 ]
If we receive a BUSY packet for a call we think we've just completed, the packet is handed off to the connection processor to deal with - but the connection processor doesn't expect a BUSY packet and so flags a protocol error.
Fix this by simply ignoring the BUSY packet for the moment.
The symptom of this may appear as a system call failing with EPROTO. This may be triggered by pressing ctrl-C under some circumstances.
This comes about we abort calls due to interruption by a signal (which we shouldn't do, but that's going to be a large fix and mostly in fs/afs/). What happens is that we abort the call and may also abort follow up calls too (this needs offloading somehoe). So we see a transmission of something like the following sequence of packets:
DATA for call N ABORT call N DATA for call N+1 ABORT call N+1
in very quick succession on the same channel. However, the peer may have deferred the processing of the ABORT from the call N to a background thread and thus sees the DATA message from the call N+1 coming in before it has cleared the channel. Thus it sends a BUSY packet[*].
[*] Note that some implementations (OpenAFS, for example) mark the BUSY packet with one plus the callNumber of the call prior to call N. Ordinarily, this would be call N, but there's no requirement for the calls on a channel to be numbered strictly sequentially (the number is required to increase).
This is wrong and means that the callNumber in the BUSY packet should be ignored (it really ought to be N+1 since that's what it's in response to).
Signed-off-by: David Howells dhowells@redhat.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Sasha Levin alexander.levin@verizon.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/rxrpc/conn_event.c | 4 ++++ 1 file changed, 4 insertions(+)
--- a/net/rxrpc/conn_event.c +++ b/net/rxrpc/conn_event.c @@ -275,6 +275,10 @@ static int rxrpc_process_event(struct rx rxrpc_conn_retransmit_call(conn, skb); return 0;
+ case RXRPC_PACKET_TYPE_BUSY: + /* Just ignore BUSY packets for now. */ + return 0; + case RXRPC_PACKET_TYPE_ABORT: if (skb_copy_bits(skb, sizeof(struct rxrpc_wire_header), &wtmp, sizeof(wtmp)) < 0)
Patches currently in stable-queue which might be from dhowells@redhat.com are
queue-4.9/afs-flush-outstanding-writes-when-an-fd-is-closed.patch queue-4.9/afs-fix-the-maths-in-afs_fs_store_data.patch queue-4.9/afs-populate-group-id-from-vnode-status.patch queue-4.9/afs-prevent-callback-expiry-timer-overflow.patch queue-4.9/crypto-rsa-fix-buffer-overread-when-stripping-leading-zeroes.patch queue-4.9/afs-adjust-mode-bits-processing.patch queue-4.9/rxrpc-wake-up-the-transmitter-if-rx-window-size-increases-on-the-peer.patch queue-4.9/afs-invalid-op-id-should-abort-with-rxgen_opcode.patch queue-4.9/afs-fix-page-leak-in-afs_write_begin.patch queue-4.9/afs-better-abort-and-net-error-handling.patch queue-4.9/afs-fix-missing-put_page.patch queue-4.9/afs-migrate-vlocation-fields-to-64-bit.patch queue-4.9/rxrpc-ignore-busy-packets-on-old-calls.patch queue-4.9/afs-populate-and-use-client-modification-time.patch queue-4.9/afs-fix-afs_kill_pages.patch queue-4.9/afs-fix-abort-on-signal-while-waiting-for-call-completion.patch