On Mon, 25 May 2026 17:16:18 +0200 Stefano Garzarella <[email protected]> wrote:
> On Mon, May 25, 2026 at 03:53:22PM +0100, David Laight wrote: > >On Mon, 25 May 2026 15:09:54 +0200 > >Stefano Garzarella <[email protected]> wrote: ... > >> >Indeed, I wasn't thinking. For this to even get close to overflowing > >> >we'd have to have almost all of 4G available to the 32 bit kernel taken > >> >up by this single queue. > > > >Except there is usually only 1G or 2G available to the kernel. > >And all the skb would have to contain no data. > > `skb_overhead` was introduced to prevent exactly queueing skb without > any data (essentially containing just the EOM for SEQPACKET) that we > plan to fix properly in some other way instead of queueing empty skb. I think most of the network code counts skb->truesize so that it limits kernel memory on the queue rather than the amount of data. This does rather rely on the low level code setting it to a sane value. Last time I looked some of the usbnet drivers lied badly. (IIRC short packets in a 64k buffer with the truesize set to the data length.) You need to do something to limit the number of single (or even zero) byte SEQPACKET messages that can be queued. -- David
