From nobody Mon Jun 8 16:28:20 2026 Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id D50F2325483 for ; Thu, 28 May 2026 07:09:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.41 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779952158; cv=none; b=Mlg3O64Y6Cx1jiI8TalpalZlDTUey3v3y+AY4fzu3O2O2i3BmWtkN0MwP5sMPNRQGPzYcbKvOS/YyOAEyNtLN8K8nkAaxzTGfuvmS5MGwIAT5eEH9qS6U/mK+MbJ6C0WF9DPXoXH4mUy+Bye99lvyKCXaaJdvbBszJk2v4VLb28= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779952158; c=relaxed/simple; bh=Lp2Ydd/vhQzgxvdtJ+PaO4rkfpJ1qSAj7X4wYdE5Rj8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=SXzKkVkFEBG909XkB052O5XDP4fWzPw+aofmRESnu9tDt3MI/m5LlGRWFc0HiKX7sE8bXBxikdvQkwhBu3Ai5Ci3f2kH1zqOzuG7rI5OM1U9iGtmQHZVrDmaefQ5KSNFDH3HLBCNGBM67foI5hRN6uCT+ind4BY0MaEjilerxtk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=NupAQkSK; arc=none smtp.client-ip=209.85.221.41 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="NupAQkSK" Received: by mail-wr1-f41.google.com with SMTP id ffacd0b85a97d-43d76dd4ee8so7662387f8f.2 for ; Thu, 28 May 2026 00:09:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779952155; x=1780556955; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=AyhxEIcTaJ0tE2zF05eMkIwg9pnZjsy1bH02V+XNbGM=; b=NupAQkSKEzA0m2qsXXhFuz8Okjwzejoaz4ydIbB/bq3rv+A+V62RibeV/0eOWmSPgw EXhTRitsxrcyr+ZAGsyL7GWzyNBRhqXQucn28/glp2E18IvYYy3Y5OAI694/LpK74MOT QQO31oS0vF67DCMVNoE8xBj2L/7QoT5veFOA+ZvR4qO00qfoguRTT9BBPMRvxFKzv9aN w0TxZUYpH6DcYMnJd8KtDfhQ92LXqHpEgJS83jiTX/GGwGXJV6qrI2zjBtYOtYWI6Lxj d9CmxENw5x3wm2roPJN2GhpLcMwL19BiKvLebVlqlfNK7+OO45B+YLENrtTJcVeQDZMQ hveQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779952155; x=1780556955; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=AyhxEIcTaJ0tE2zF05eMkIwg9pnZjsy1bH02V+XNbGM=; b=Gzs2+Z1mVSN3ZAFo7D7zIYaoNhtwJYXoyZurhveCfTS71AGf6ymxcr8kTMDo54SPsH rD0ZHskZIvfMC6dkEj+PshYvoMmHaSQwTNp06zDCY1sXBXq5ti8ccogZCsGLIM8YmmLf I/jtnD3hy3MmILLa+8kKL4Y+2NWWXHm2IxZlpI3jIyWOi+N13WHFwLE3TgOWY1rdPp9t yqyGplhQzYUCLgSu8xQ/5QPTNN6aHHt4PLGocUcJe3ielW21a9vXkUwQze9uHt5Deyg2 MqI9zWZFh0XBDuecEgEMWT6c3HVi77EwLBDGW9ocCsyKUvB+QQKFLrf7t4blXQK5rMQs V8ew== X-Forwarded-Encrypted: i=1; AFNElJ/5g3wziarr1LpNUdSShlOpmT+uyyAoPcv9QxYkSHPIXJGENuBbQd2TLSyxKyWVL0F8p1e/UhDMaF8ThiA=@vger.kernel.org X-Gm-Message-State: AOJu0YwNboD+VmuXmVlBE5PSUTTbtni22BZgmZcAnEIf2DcWOtzS7q1L FgPPr2/YpjYe8q7E3IwmllZUg1UchmbWD7/hg8v+IGsQaU6FcwMY1gVHf1yj6NTwX/8= X-Gm-Gg: Acq92OHyHU1liEirNInkIYGwgr/hxBB4Q+QOp03Xz4kPQRLogdpusipyGX/dG7MUuoi 1Wx0MpV+goJvvaXD6NW5vTfJn7tCdebyaQ6cB6OVN2TbK2IbBE+Fav0JmDIpkkatZcnEtqtbl/V evEvR+moeuHNTo9wcjKT3FZZ3p4pdZFvynM9Gpo3AG1VbKzXxRzMMWRGpnvQJfK22SSkJQd4hvm hlp8MnMNj7+nXzS50BdTc41f9uX6mPA29sVlxZ3HdcDnrncXDCPQT3mDcxVZnY9Vtq6cbzHX63a ftyJLU5lgKb/R+49Nfc7BWToG1va9RSzwx/x6RKfPVULdmm+ExRBKI5P6dlt+t6GO90igIoVxsE WreuWDC8wULlTpowk2TosHqzbqHlZfja89vso6YE2orzCaayJssG7ITN4Ib/zwLqjXqTukQy1M8 BFCkQnKALjoVydoNuQOv15aPE6FNQI7GnOYzq3OCiXSNFOPfI43qowC3gZdN4aPKwxZSwr0bYxi +/UhRVsd++yCmqonQxaUkmCpbmE X-Received: by 2002:a5d:5846:0:b0:45e:e5d1:8a74 with SMTP id ffacd0b85a97d-45ee5d18b41mr2471256f8f.14.1779952155005; Thu, 28 May 2026 00:09:15 -0700 (PDT) Received: from localhost.localdomain ([188.27.64.216]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-45ee91c34bfsm2722402f8f.2.2026.05.28.00.09.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 28 May 2026 00:09:14 -0700 (PDT) From: Adrian Bente To: pablo@netfilter.org, kadlec@netfilter.org, fw@strlen.de, netfilter-devel@vger.kernel.org Cc: phil@nwl.cc, davem@davemloft.net, edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, horms@kernel.org, nbd@nbd.name, sean.wang@mediatek.com, lorenzo@kernel.org, andrew+netdev@lunn.ch, matthias.bgg@gmail.com, angelogioacchino.delregno@collabora.com, daniel@makrotopia.org, coreteam@netfilter.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-mediatek@lists.infradead.org, Adrian Bente , stable@vger.kernel.org Subject: [PATCH v2 net] netfilter: flowtable: fix offloaded ct timeout never being extended Date: Thu, 28 May 2026 10:08:51 +0300 Message-ID: <20260528070851.3913-1-adibente@gmail.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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. Suggested-by: Florian Westphal Fixes: 03428ca5cee9 ("netfilter: conntrack: rework offload nf_conn timeout = extension logic") Cc: stable@vger.kernel.org Signed-off-by: Adrian Bente --- v2: - open-code expires from an absolute READ_ONCE(ct->timeout) snapshot instead of the relative nf_ct_expires() value (Florian Westphal) - change min_timeout to s32 to keep the comparison signed - initialise new_timeout to 1 instead of true net/netfilter/nf_flow_table_core.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/net/netfilter/nf_flow_table_core.c b/net/netfilter/nf_flow_tab= le_core.c index 3313f82..a2d08e5 100644 --- a/net/netfilter/nf_flow_table_core.c +++ b/net/netfilter/nf_flow_table_core.c @@ -500,8 +500,13 @@ */ static void nf_flow_table_extend_ct_timeout(struct nf_conn *ct) { - static const u32 min_timeout =3D 5 * 60 * HZ; - u32 expires =3D nf_ct_expires(ct); + static const s32 min_timeout =3D 5 * 60 * HZ; + u32 ct_timeout =3D READ_ONCE(ct->timeout); + s32 expires; + + expires =3D ct_timeout - nfct_time_stamp; + if (expires <=3D 0) /* already expired */ + return; =20 /* normal case: large enough timeout, nothing to do. */ if (likely(expires >=3D min_timeout)) @@ -519,7 +524,7 @@ static void nf_flow_table_extend_ct_timeout(struct nf_c= onn *ct) if (nf_ct_is_confirmed(ct) && test_bit(IPS_OFFLOAD_BIT, &ct->status)) { u8 l4proto =3D nf_ct_protonum(ct); - u32 new_timeout =3D true; + u32 new_timeout =3D 1; =20 switch (l4proto) { case IPPROTO_UDP: @@ -544,7 +549,7 @@ static void nf_flow_table_extend_ct_timeout(struct nf_c= onn *ct) */ if (new_timeout) { new_timeout +=3D nfct_time_stamp; - cmpxchg(&ct->timeout, expires, new_timeout); + cmpxchg(&ct->timeout, ct_timeout, new_timeout); } } =20 --=20 2.43.0