Re: [PATCH] PPPOE can kfree SKB twice (was Re: kernel panic problem. (smp, iptables?))

[Michal Ostrowski]

"David S. Miller" <[e-mail]> writes:
> 
> This report has been plagueing us for a month or two now, from
> different people.  But we hadn't been able to track it down.
> 
> Initially we believed it might be some obscure bug in netfilter
> which got triggered more easily when the zerocopy stuff went in.
> But all of our code audits turned up nothing.

This brings up an interesting point.

One of the initial issues in developing PPPoE support was how to
ensure that the layers passing packets to PPPoE allocated the correct
amount of header space in the skb (so as to avoid a copy of the skb to
create space for PPPoE headers).

This issue was resolved by having the PPP layer respect the header
lengths specified by the underlying transport layers (PPPoE) when
defining dev->hard_header_len.  However, just to be on the safe side,
this code that copied the packet was left in place.

My guess is that before zerocopy netfilter, netfilter made an skb that
conformed to the header requirements of PPPoE.  Once netfilter stopped
making copies PPPoE was passed skb's without space for PPPoE headers
and thus invoked the code path you've just fixed.

Is it possible for netfilter to pass to the PPP device a packet that
respect's the PPP device's hard_header_len? (This would avoid the copy
in PPPoE.)  More generally, I'm concerned (without having seen the
code) that we may have problems when passing skb's between devices via
zerocopy-netfilter when those devices have varying hard_header_len
requirements.

> 
> I have no way to test out these changes, so can folks do that for me?
> If I didn't screw something else up, then I'm pretty sure the OOPS
> will go away.  Let me know if something goes wrong due to these
> changes.
> 

As far as I can tell it all seems fine.  (I'd like to hear some
success stories from some of the people using netfilter heavily with
this though who have experienced the oops'es.)

Michal Ostrowski
[e-mail]