Re: ebtables_nfqueue: missing structure afinfo

[Patrick McHardy <kaber@trash.net>]

Am 02.02.2011 20:22, schrieb Pierre Chifflier:
> I've spent a few days trying to make it optional (in nf_queue.c,
> function __nf_queue), however I have a weird problem:
> If I remove the test for afinfo (and ensure that the pointer is not used
> if null), everything seems to work fine.
> However, when I use a userspace program (always returning NF_ACCEPT), I
> got a fatal kernel oops (or panic) regarding packets.
> According to the info displayed, it seems to be sometimes in
> br_handle_frame, at
> this point:
> 	case BR_STATE_FORWARDING:
> 		rhook = rcu_dereference(br_should_route_hook);
> 		if (rhook) {
> 			if ((*rhook)(skb))
> 
> inside the (*rhook) call.

It shouldn't even get to this function since this is before the
NF_HOOK calls.

> Sometimes it's in netlink_unicast (unknown location), always when
> reinjecting packet.
> 
> I tried to get more info with kgdb, but without much success:
> #2  0xc11d1adc in skb_release_all (skb=0xdf1ed600) at net/core/skbuff.c:403
> #3  __kfree_skb (skb=0xdf1ed600) at net/core/skbuff.c:417
> #4  0xc11d1bdb in kfree_skb (skb=0xdf1ed600) at net/core/skbuff.c:438
> #5  0xc11ee4d1 in netlink_unicast (ssk=0xdbf15c00, skb=<value optimized
> out>,
>     pid=<value optimized out>, nonblock=0) at net/netlink/af_netlink.c:921
> 
> Any idea on what could cause this ? AFAICT, it was not happening when I
> used a fake afinfo structure.

No. Please send over the code you're using and I'll have a closer look.