Re: [REGRESSION] v6.16 system hangs (bisected to nf_conntrack fix)

[Florian Westphal <fw@strlen.de>]

Dan Moulding <dan@danm.net> wrote:
> Ok. I just tried reverting only the changes to nf_conntrack_core.c and
> the hang no longer occurs. This is on top of 6.16.

Strange.  Can you completely revert 2d72afb340657f03f7261e9243b44457a9228ac7
and then apply this patch instead?

diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -984,6 +984,7 @@ static void __nf_conntrack_insert_prepare(struct nf_conn *ct)
        struct nf_conn_tstamp *tstamp;

        refcount_inc(&ct->ct_general.use);
+       ct->status |= IPS_CONFIRMED;

        /* set conntrack timestamp, if enabled. */
        tstamp = nf_conn_tstamp_find(ct);
@@ -1260,8 +1261,6 @@ __nf_conntrack_confirm(struct sk_buff *skb)
         * user context, else we insert an already 'dead' hash, blocking
         * further use of that particular connection -JM.
         */
-       ct->status |= IPS_CONFIRMED;
-
        if (unlikely(nf_ct_is_dying(ct))) {
                NF_CT_STAT_INC(net, insert_failed);
                goto dying;



(the confirm-bit-set moves from the too-early spot in __nf_conntrack_confirm
 to __nf_conntrack_insert_prepare).

Unlike 2d72afb340657f03f7261e9243b44457a9228ac7 its still set before
hash insertion, but we no longer set it on entries that were not
inserted into the hash.

Unfortunately I still do not see why setting the bit after hashtable
insertion causes problems.  ____nf_conntrack_find() should skip/ignore
the entry, and I don't see how it causes an infinite loop or
double-insert or whatever else is causing this hang.