From: "João Silva" <jgc3silva@gmail.com>
To: Pablo Neira Ayuso <pablo@netfilter.org>
Cc: Florian Westphal <fw@strlen.de>, Phil Sutter <phil@nwl.cc>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Simon Horman <horms@kernel.org>,
Sven Auhagen <sven.auhagen@voleatech.de>,
Oz Shlomo <ozsh@nvidia.com>,
netfilter-devel@vger.kernel.org, coreteam@netfilter.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH nf] netfilter: flowtable: do not clear the offload bit twice
Date: Thu, 5 Nov 2026 11:25:13 +0000 [thread overview]
Message-ID: <33ae075d-1178-477f-b57d-927b1dffae0d@gmail.com> (raw)
In-Reply-To: <ausaF4X_RieUIjxg@chamomile>
Hi,
Sorry for the late reply. It is infact out-of-tree. Will resend against
nf-next.
Thanks,
João Silva
On 04/11/26 11:42, Pablo Neira Ayuso wrote:
> On Tue, Nov 03, 2026 at 06:56:30PM +0000, João Silva wrote:
>> Hi,
>>
>> The fix was LLM generated but I wouldn't say it's just "for correctness".
>> For some context, this issue was hit while developing hardware-offloaded
>> flows for the RTL930x target in openwrt. There was a point in development
>> where this was causing flows to pile up and eventually exhaust the TCAM of
>> the PIE engine on the switch.
> Good, but that is not an out-tree driver?
>
> If so, this should follow nf-next.
>
> Thanks
>
>> Thanks for considering.
>>
>> João Silva
>>
>>
>> On 03/11/26 13:59, Pablo Neira Ayuso wrote:
>>> On Tue, Nov 03, 2026 at 09:52:56AM +0000, João Silva via B4 Relay wrote:
>>>> From: João Silva <jgc3silva@gmail.com>
>>>>
>>>> An expired hardware flow remains in the flowtable until its asynchronous
>>>> hardware deletion completes. Teardown clears IPS_OFFLOAD_BIT, so a packet
>>>> can create a replacement flow referencing the same conntrack entry while
>>>> the old flow is still waiting for deletion.
>>>>
>>>> The next GC pass calls flow_offload_teardown() on the expired old flow
>>>> again, clearing the replacement's offload bit. More packets can then
>>>> create additional flows for the same conntrack entry. A pending hardware
>>>> work item can also delay deletion and expose the same repeated teardown.
>>>>
>>>> Commit d2d31ea8cd80 ("netfilter: conntrack: fix erronous removal of
>>>> offload bit") closed this window for software flows by unlinking them in
>>>> the same GC pass and made the conntrack state fixup one-shot, but
>>>> hardware flows stay linked until NF_FLOW_HW_DEAD is set.
>>>>
>>>> Make clearing IPS_OFFLOAD_BIT part of the existing one-time teardown
>>>> transition, alongside the conntrack state fixup. Subsequent teardown calls
>>>> must not alter the offload state now owned by a replacement flow.
>>> Let's better target nf-next for this, this looks like LLM triggered
>>> for correctness.
>>>
>>> Thanks.
>>>
>>>> Fixes: e5eaac2beb54 ("netfilter: flowtable: fix TCP flow teardown")
>>>> Signed-off-by: João Silva <jgc3silva@gmail.com>
>>>> ---
>>>> net/netfilter/nf_flow_table_core.c | 6 ++++--
>>>> 1 file changed, 4 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/net/netfilter/nf_flow_table_core.c b/net/netfilter/nf_flow_table_core.c
>>>> index 0d72dc8ae47a..709b55b74cc7 100644
>>>> --- a/net/netfilter/nf_flow_table_core.c
>>>> +++ b/net/netfilter/nf_flow_table_core.c
>>>> @@ -398,9 +398,11 @@ static void flow_offload_del(struct nf_flowtable *flow_table,
>>>> void flow_offload_teardown(struct flow_offload *flow)
>>>> {
>>>> + if (test_and_set_bit(NF_FLOW_TEARDOWN, &flow->flags))
>>>> + return;
>>>> +
>>>> clear_bit(IPS_OFFLOAD_BIT, &flow->ct->status);
>>>> - if (!test_and_set_bit(NF_FLOW_TEARDOWN, &flow->flags))
>>>> - flow_offload_fixup_ct(flow);
>>>> + flow_offload_fixup_ct(flow);
>>>> }
>>>> EXPORT_SYMBOL_GPL(flow_offload_teardown);
>>>>
>>>> ---
>>>> base-commit: 734bef548a96e8774d6eef5dfa2026c6edc4e80b
>>>> change-id: 20261103-flowtable-offload-bit-f15bfd1d38ed
>>>>
>>>> Best regards,
>>>> --
>>>> João Silva <jgc3silva@gmail.com>
>>>>
>>>>
prev parent reply other threads:[~2026-11-05 11:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 9:52 [PATCH nf] netfilter: flowtable: do not clear the offload bit twice João Silva via B4 Relay
2026-11-03 9:52 ` João Silva
2026-11-03 9:59 ` netdev-bot+sinfo
2026-11-03 13:59 ` Pablo Neira Ayuso
2026-11-03 18:56 ` João Silva
2026-11-04 11:42 ` Pablo Neira Ayuso
2026-11-05 11:25 ` João Silva [this message]
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=33ae075d-1178-477f-b57d-927b1dffae0d@gmail.com \
--to=jgc3silva@gmail.com \
--cc=coreteam@netfilter.org \
--cc=davem@davemloft.net \
--cc=edumazet@kernel.org \
--cc=fw@strlen.de \
--cc=horms@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=ozsh@nvidia.com \
--cc=pabeni@redhat.com \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
--cc=sven.auhagen@voleatech.de \
/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.