On Tue, 6 Oct 2020 08:27:34 +0200 Paolo Abeni wrote: > If recvmsg() and the workqueue race to dequeue the data > pending on some subflow, the current mapping for such > subflow covers several skbs and some of them have not > reached yet the received, either the worker or recvmsg() > can find a subflow with the data_avail flag set - since > the current mapping is valid and in sequence - but no > skbs in the receive queue - since the other entity just > processed them. > > The above will lead to an unbounded loop in __mptcp_move_skbs() > and a subsequent hang of any task trying to acquiring the msk > socket lock. > > This change addresses the issue stopping the __mptcp_move_skbs() > loop as soon as we detect the above race (empty receive queue > with data_avail set).
Applied, thanks!