On Sun, 16 Aug 2020 23:14:20 +0200 Florian Westphal wrote:
> This fix wasn't correct: When this function is invoked from the
> retransmission worker, the iterator contains garbage and resetting
> it causes a crash.
>
> As the work queue should not be performance critical also zero the
> msghdr str
From: Florian Westphal
Date: Sun, 16 Aug 2020 23:14:20 +0200
> This fix wasn't correct: When this function is invoked from the
> retransmission worker, the iterator contains garbage and resetting
> it causes a crash.
>
> As the work queue should not be performance critical also zero the
> msghdr
This fix wasn't correct: When this function is invoked from the
retransmission worker, the iterator contains garbage and resetting
it causes a crash.
As the work queue should not be performance critical also zero the
msghdr struct.
Fixes: 35759383133f64d "(mptcp: sendmsg: reset iter on error)"
Si
From: Florian Westphal
Date: Fri, 14 Aug 2020 15:56:34 +0200
> Once we've copied data from the iterator we need to revert in case we
> end up not sending any data.
>
> This bug doesn't trigger with normal 'poll' based tests, because
> we only feed a small chunk of data to kernel after poll indic
On Fri, 14 Aug 2020, Florian Westphal wrote:
Once we've copied data from the iterator we need to revert in case we
end up not sending any data.
This bug doesn't trigger with normal 'poll' based tests, because
we only feed a small chunk of data to kernel after poll indicated
POLLOUT. With block
Once we've copied data from the iterator we need to revert in case we
end up not sending any data.
This bug doesn't trigger with normal 'poll' based tests, because
we only feed a small chunk of data to kernel after poll indicated
POLLOUT. With blocking IO and large writes this triggers. Receiver
