lkml.org 
[lkml]   [2023]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: Endless loop in udp with MSG_SPLICE_READ - Re: [syzbot] [fs?] INFO: task hung in pipe_release (4)
Date
The more I look at __ip_append_data(), the more I think the maths is wrong.
In the bit that allocates a new skbuff:

if (copy <= 0) {
...
datalen = length + fraggap;
if (datalen > mtu - fragheaderlen)
datalen = maxfraglen - fragheaderlen;
fraglen = datalen + fragheaderlen;
pagedlen = 0;
...
if ((flags & MSG_MORE) &&
!(rt->dst.dev->features&NETIF_F_SG))
...
else if (!paged &&
(fraglen + alloc_extra < SKB_MAX_ALLOC ||
!(rt->dst.dev->features & NETIF_F_SG)))
...
else {
alloclen = fragheaderlen + transhdrlen;
pagedlen = datalen - transhdrlen;
}
...

In the MSG_SPLICE_READ but not MSG_MORE case, we go through that else clause.
The values used here, a few lines further along:

copy = datalen - transhdrlen - fraggap - pagedlen;

are constant over the intervening span. This means that, provided the splice
isn't going to exceed the MTU on the second fragment, the calculation of
'copy' can then be simplified algebraically thus:

copy = (length + fraggap) - transhdrlen - fraggap - pagedlen;

copy = length - transhdrlen - pagedlen;

copy = length - transhdrlen - (datalen - transhdrlen);

copy = length - transhdrlen - datalen + transhdrlen;

copy = length - datalen;

copy = length - (length + fraggap);

copy = length - length - fraggap;

copy = -fraggap;

I think we might need to recalculate copy after the conditional call to
getfrag(). Possibly we should skip that entirely for MSG_SPLICE_READ. The
root seems to be that we're subtracting pagedlen from datalen - but probably
we shouldn't be doing getfrag() if pagedlen > 0.

David

\
 
 \ /
  Last update: 2023-08-01 14:42    [W:1.253 / U:1.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site