[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1210667528.3646.28.camel@johannes.berg>
Date: Tue, 13 May 2008 10:32:08 +0200
From: Johannes Berg <johannes@...solutions.net>
To: David Miller <davem@...emloft.net>
Cc: netdev@...r.kernel.org, herbert@...dor.apana.org.au
Subject: Re: [RFC/T] [NET] make pskb_expand_head warn when called with
invalid state
> > > [23194.608077] [ccf9bba0] [c02735a0] pskb_expand_head+0x58/0x1f8 (unreliable)
> > > [23194.608082] [ccf9bbc0] [c02737a4] __pskb_pull_tail+0x64/0x374
> >
> > 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 the
> > 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.
> 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.
> 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.
> 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
Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)
Powered by blists - more mailing lists