[PATCH net] rxrpc: Kernel calls get stuck in recvmsg

David Miller davem at davemloft.net
Sun Feb 26 18:31:04 PST 2017


From: David Howells <dhowells at redhat.com>
Date: Fri, 24 Feb 2017 21:57:13 +0000

> Calls made through the in-kernel interface can end up getting stuck because
> of a missed variable update in a loop in rxrpc_recvmsg_data().  The problem
> is like this:
> 
>  (1) A new packet comes in and doesn't cause a notification to be given to
>      the client as there's still another packet in the ring - the
>      assumption being that if the client will keep drawing off data until
>      the ring is empty.
> 
>  (2) The client is in rxrpc_recvmsg_data(), inside the big while loop that
>      iterates through the packets.  This copies the window pointers into
>      variables rather than using the information in the call struct
>      because:
> 
>      (a) MSG_PEEK might be in effect;
> 
>      (b) we need a barrier after reading call->rx_top to pair with the
>      	 barrier in the softirq routine that loads the buffer.
> 
>  (3) The reading of call->rx_top is done outside of the loop, and top is
>      never updated whilst we're in the loop.  This means that even through
>      there's a new packet available, we don't see it and may return -EFAULT
>      to the caller - who will happily return to the scheduler and await the
>      next notification.
> 
>  (4) No further notifications are forthcoming until there's an abort as the
>      ring isn't empty.
> 
> The fix is to move the read of call->rx_top inside the loop - but it needs
> to be done before the condition is checked.
> 
> Reported-by: Marc Dionne <marc.dionne at auristor.com>
> Signed-off-by: David Howells <dhowells at redhat.com>
> Tested-by: Marc Dionne <marc.dionne at auristor.com>

Applied, thanks.



More information about the linux-afs mailing list