[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1403253.1690898464@warthog.procyon.org.uk>
Date: Tue, 01 Aug 2023 15:01:04 +0100
From: David Howells <dhowells@...hat.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
Cc: dhowells@...hat.com, Jakub Kicinski <kuba@...nel.org>,
syzbot <syzbot+f527b971b4bdc8e79f9e@...kaller.appspotmail.com>,
bpf@...r.kernel.org, brauner@...nel.org, davem@...emloft.net,
dsahern@...nel.org, edumazet@...gle.com,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, pabeni@...hat.com,
syzkaller-bugs@...glegroups.com, viro@...iv.linux.org.uk
Subject: Re: Endless loop in udp with MSG_SPLICE_READ - Re: [syzbot] [fs?] INFO: task hung in pipe_release (4)
Willem de Bruijn <willemdebruijn.kernel@...il.com> wrote:
> That getfrag is needed. For non-splice cases, to fill the linear part
> of an skb. As your example shows, it is skipped if all data is covered
> by pagedlen?
Yes, because copy goes negative. To quote from the previously quoted log:
==>splice_to_socket() 6630
udp_sendmsg(8,8)
__ip_append_data(copy=-1,len=8, mtu=8192 skblen=8189 maxfl=8188)
pagedlen 9 = 9 - 0
copy -1 = 9 - 0 - 1 - 9
copy is -(the number of excess bytes).
length 8 -= -1 + 0
which then gets deducted from the length - but why? I wonder if copy should
be cleared if we don't call getfrag(). It looks like it's meant to deduct the
amount copied by getfrag(), but that doesn't happen if copy < 0.
Also, note that MSG_ZEROCOPY might see the same maths issue here.
David
Powered by blists - more mailing lists