From: "Linus Lüssing" <linus.luessing@c0d3.blue>
To: netfilter-devel@vger.kernel.org
Cc: b.a.t.m.a.n@lists.open-mesh.org
Subject: Re: [B.A.T.M.A.N.] "Kernel bug detected [...] nf_ct_del_from_dying_or_unconfirmed_list"
Date: Tue, 29 Jan 2019 10:07:54 +0100 [thread overview]
Message-ID: <20190129090754.GB1528@otheros> (raw)
In-Reply-To: <20190127214708.GC1788@otheros>
On Sun, Jan 27, 2019 at 10:47:08PM +0100, Linus Lüssing wrote:
[...]
> The crash itself is triggered by the:
>
> BUG_ON(hlist_nulls_unhashed(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode));
>
> in here:
>
> https://elixir.bootlin.com/linux/v4.9.146/source/net/netfilter/nf_conntrack_core.c#L354
I had tried the nf_reset()s and Wang's patch but with no success.
Skimming through the code I noticed that there aren't that many
opportunities for the hnnode to become zero. There are several
hlist_nulls_del_rcu(), but no hlist_nulls_del_init_rcu()s for
instance.
That started to make me wonder whether something from "outside"
might be setting the hnnode to zero - and yeah...
I missed that batadv_send_skb_unicast() always frees/consumes the
skb... and I was freeing the skb myself if that call returned
!NET_XMIT_SUCCESS. So a double kfree_skb()... I'm a bit surprised
that things did not crash more often...
Sorry for the noise :-(. But thanks for all the help and quick
responses!
WARNING: multiple messages have this Message-ID (diff)
From: "Linus Lüssing" <linus.luessing-djzkFPsfvsizQB+pC5nmwQ@public.gmane.org>
To: netfilter-devel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: b.a.t.m.a.n-ZwoEplunGu2X36UT3dwllkB+6BGkLq7r@public.gmane.org
Subject: Re: "Kernel bug detected [...] nf_ct_del_from_dying_or_unconfirmed_list"
Date: Tue, 29 Jan 2019 10:07:54 +0100 [thread overview]
Message-ID: <20190129090754.GB1528@otheros> (raw)
In-Reply-To: <20190127214708.GC1788@otheros>
On Sun, Jan 27, 2019 at 10:47:08PM +0100, Linus Lüssing wrote:
[...]
> The crash itself is triggered by the:
>
> BUG_ON(hlist_nulls_unhashed(&ct->tuplehash[IP_CT_DIR_ORIGINAL].hnnode));
>
> in here:
>
> https://elixir.bootlin.com/linux/v4.9.146/source/net/netfilter/nf_conntrack_core.c#L354
I had tried the nf_reset()s and Wang's patch but with no success.
Skimming through the code I noticed that there aren't that many
opportunities for the hnnode to become zero. There are several
hlist_nulls_del_rcu(), but no hlist_nulls_del_init_rcu()s for
instance.
That started to make me wonder whether something from "outside"
might be setting the hnnode to zero - and yeah...
I missed that batadv_send_skb_unicast() always frees/consumes the
skb... and I was freeing the skb myself if that call returned
!NET_XMIT_SUCCESS. So a double kfree_skb()... I'm a bit surprised
that things did not crash more often...
Sorry for the noise :-(. But thanks for all the help and quick
responses!
next prev parent reply other threads:[~2019-01-29 9:07 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-27 21:47 [B.A.T.M.A.N.] "Kernel bug detected [...] nf_ct_del_from_dying_or_unconfirmed_list" Linus Lüssing
2019-01-27 21:47 ` Linus Lüssing
2019-01-27 22:48 ` [B.A.T.M.A.N.] " Florian Westphal
2019-01-27 22:48 ` Florian Westphal
2019-01-28 13:35 ` [B.A.T.M.A.N.] " Chieh-Min Wang
2019-01-28 13:35 ` Chieh-Min Wang
2019-01-28 13:39 ` [B.A.T.M.A.N.] " Florian Westphal
2019-01-28 13:39 ` Florian Westphal
2019-01-28 13:50 ` [B.A.T.M.A.N.] " Pablo Neira Ayuso
2019-01-28 13:50 ` Pablo Neira Ayuso
2019-01-28 14:01 ` [B.A.T.M.A.N.] " Florian Westphal
2019-01-28 14:01 ` Florian Westphal
2019-01-28 14:03 ` [B.A.T.M.A.N.] " Chieh-Min Wang
2019-01-28 14:03 ` Chieh-Min Wang
2019-01-28 14:13 ` [B.A.T.M.A.N.] " Florian Westphal
2019-01-28 14:13 ` Florian Westphal
2019-01-28 14:16 ` [B.A.T.M.A.N.] " Chieh-Min Wang
2019-01-28 14:16 ` Chieh-Min Wang
2019-01-28 14:25 ` [B.A.T.M.A.N.] " Chieh-Min Wang
2019-01-28 14:25 ` Chieh-Min Wang
2019-01-29 9:07 ` Linus Lüssing [this message]
2019-01-29 9:07 ` Linus Lüssing
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190129090754.GB1528@otheros \
--to=linus.luessing@c0d3.blue \
--cc=b.a.t.m.a.n@lists.open-mesh.org \
--cc=netfilter-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.