Dan Moulding <dan@xxxxxxxx> 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.
