> > > [23194.608077] [ccf9bba0] [c02735a0] pskb_expand_head+0x58/0x1f8 (unr=
eliable)
quoted text > > > [23194.608082] [ccf9bbc0] [c02737a4] __pskb_pull_tail+0x64/0x374
> >=20
> > It's actually not really a false positive. What is happening is that
> > __pskb_pull_tail does (follow 'eat'):
> ...
> > which of course changes the true size of the skb without accounting it
> > to the socket. Now, the reason this hasn't been known before is that th=
e
quoted text > > data size doesn't change because the stuff that is copied into the
> > header is removed from the data_len... or something like that, I think.
quoted text > Is this from a kernel with your GSO wireless patches applied by
> chance? :-)
Yes, but I'm pretty sure it wasn't using that code path since the
interface was down when this occurred.
quoted text > FWIW, the only practical case where this can occur is for an SG+CSUM
> device which cannot handle DMA'ing highmem pages, and we get such a
> page via sendfile() or similar.
That's well possible since I'm using sungem and it says "no highdma" but
"sg/hwcsum" for my hardware, and I do have highmem.
=EF=BB=BF
quoted text > I think we need to do some more fixups and auditing before we can
> enable this pskb_expand_head() assertion, and the same goes for
> your more-accurate skb_truesize_check().
Yeah, looks like.
johannes
