summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorAdrian Bente <adibente@gmail.com>2026-05-28 10:08:51 +0300
committerPablo Neira Ayuso <pablo@netfilter.org>2026-06-19 10:54:01 +0200
commit53b3e60edb674b442b2b3bbdba484667b0f47a5d (patch)
tree619c2c566b1074b398b6f8f28e20ace11905fd63 /include
parent96e7f9122aae0ed000ee321f324b812a447906d9 (diff)
netfilter: flowtable: fix offloaded ct timeout never being extended
OpenWrt has recently migrated many platforms to kernel 6.18. On the MediaTek platform, which supports hardware network offloading, WiFi connections accelerated via the WED path were observed to drop after roughly 300 seconds. After several debugging sessions, assisted by the Claude LLM, the problem was narrowed down as follows: nf_flow_table_extend_ct_timeout() extends ct->timeout for offloaded flows using: cmpxchg(&ct->timeout, expires, new_timeout); 'expires' comes from nf_ct_expires(ct) and is a relative value, while ct->timeout holds an absolute timestamp. The two are never equal, so the cmpxchg always fails and the timeout is never extended. This goes unnoticed for most flows, but a long-lived hardware (WED) offloaded flow on MediaTek MT7986 eventually has ct->timeout decay to zero, the conntrack entry is reaped and the connection breaks. Open-code the relative value from a single READ_ONCE(ct->timeout) snapshot and compare against that same absolute snapshot in the cmpxchg, so the timeout extension actually takes effect while the datapath remains authoritative if it updates ct->timeout concurrently. Fixes: 03428ca5cee9 ("netfilter: conntrack: rework offload nf_conn timeout extension logic") Cc: stable@vger.kernel.org Suggested-by: Florian Westphal <fw@strlen.de> Signed-off-by: Adrian Bente <adibente@gmail.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions