Re: problem with conntrack utility and kernel 2.6.14

[Patrick McHardy <kaber@trash.net>]

Pablo Neira Ayuso wrote:
> Hi Patrick,
> 
> Deti Fliegl wrote:
> 
>>The kernel oops still happens - but this time I had access to the
>>console (hope that helps):
>>
>><4>Badness in __kfree_skb at net/core/skbuff.c:330
>><4>
>><4>Call Trace:<ffffffff802a2f77>{__kfree_skb+167}
>><ffffffff802bb597>{netlink_recvmsg+279}
>><4>       <ffffffff8029cb2b>{sock_recvmsg+315}
>><ffffffff8025a4d8>{n_tty_receive_buf+4392}
>><4>       <ffffffff8025a4d8>{n_tty_receive_buf+4392}
>><ffffffff8015d828>{filemap_nopage+424}
>><4>       <ffffffff8013003b>{try_to_wake_up+1083}
>><ffffffff8014b2f0>{autoremove_wake_function+0}
>><4>       <ffffffff8025bbd9>{pty_write+89}
>><ffffffff8029e38b>{sys_recvmsg+395}
>><4>       <ffffffff80130f23>{__wake_up+67}
>><ffffffff80181208>{vfs_write+344}
>><4>       <ffffffff80181343>{sys_write+83}
>><ffffffff8010dc4e>{system_call+126}
>><4>
>><3>scheduling while atomic: conntrack/0xffffff00/7887
> 
> 
> Romary Sonrier is reporting a similar problem on a i586 box:
> 
> https://bugzilla.netfilter.org/bugzilla/show_bug.cgi?id=409
> 
> I can't see a way how the ctnetlink code can trigger that oops at moment
> :(. Any clue on this?

Interesting. I guess that rules out bad hardware in Deti's case. I still
can't see how this can happen, but I'm going to have another look.