Re: [PATCH net] rxrpc: Ignore BUSY packets on old calls

[David Miller]

From: David Howells <dhowells@xxxxxxxxxx>
Date: Thu, 16 Mar 2017 16:27:10 +0000

> 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@xxxxxxxxxx>

Applied, thanks David.