forked from luck/tmp_suning_uos_patched
d7e15835ab
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@auristor.com> Signed-off-by: David Howells <dhowells@redhat.com> Tested-by: Marc Dionne <marc.dionne@auristor.com> Signed-off-by: David S. Miller <davem@davemloft.net> |
||
---|---|---|
.. | ||
af_rxrpc.c | ||
ar-internal.h | ||
call_accept.c | ||
call_event.c | ||
call_object.c | ||
conn_client.c | ||
conn_event.c | ||
conn_object.c | ||
conn_service.c | ||
input.c | ||
insecure.c | ||
Kconfig | ||
key.c | ||
local_event.c | ||
local_object.c | ||
Makefile | ||
misc.c | ||
output.c | ||
peer_event.c | ||
peer_object.c | ||
proc.c | ||
recvmsg.c | ||
rxkad.c | ||
security.c | ||
sendmsg.c | ||
skbuff.c | ||
sysctl.c | ||
utils.c |