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.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
