From nobody Mon Jun 8 22:51:23 2026 Received: from mail-wm1-f49.google.com (mail-wm1-f49.google.com [209.85.128.49]) (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 92EE9317143 for ; Tue, 26 May 2026 06:02:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779775326; cv=none; b=NIFPjUfJR1poxdFQMejJqWqGEKJSlGCX2NC6KKz0Tauz9Jah1iCbxM3K9995bxEPFofSc5WOwLfzY05CFo4PONIgnFtDQrPKLC+fHO4kek7Ij3AWk6VZkCmCnBu6LKQ25OWr5byngXQtTW8jkQJh1fA+Y0agP7zgaD3El/hyj+o= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779775326; c=relaxed/simple; bh=ChxFUaH9zjpYx8BRjD9dZ1vHU8YYLfBsQ0g0/WFsa04=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=aB7qmzRQAFMmnbczk017o9bJ4qVfdbSlpzspEwF20/olXvvKScO11/TPfT17htAZCW9rX9giaF9ut4k+gBiKsmPBgauNYjmXT1fPtOI8pB/lNzMAdzA+RERnFUnEvO6RfQT/7Sp+5neM5dM76FWpXi56EU/M0uhqd+NxMJUxLMw= 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=Q6IuZOdC; arc=none smtp.client-ip=209.85.128.49 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="Q6IuZOdC" Received: by mail-wm1-f49.google.com with SMTP id 5b1f17b1804b1-4891d7164ddso48711275e9.3 for ; Mon, 25 May 2026 23:02:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1779775323; x=1780380123; 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=I15Qye72rXnWF52br0qRQsOfcY4+owD8kwcdhmYsCXA=; b=Q6IuZOdCTtzoZaDj/nzDRpZatytcBKlnePx4JQLKE82LcAmYjUMNJYGJYxw3RmWQkz /awJktpuJ+ZhScg8WdbZ981evwEsmTR3oQTzg4E9yjjou6iAt7thD1u1Alh5mxDlKUQH BwwSMFXDDHpYkTVf+iNe+y/WM1C1V6pweNWYzDf+Ix3fE+IA8SQ8WHkRPNCAwwQGrZVi 8fpKs8xI5GoGrgGMBk1A5u89cbK95zR7XykcT0qJbTFHAUPXkexux6zAlyvGZuLMBiDk ySln2gzsFWHdIBDUXFfBRcy3ocBQaQSyoHdIDjzt3PDcPnuibYX2ebWvNPGJzSYWYkNh z9BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1779775323; x=1780380123; 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=I15Qye72rXnWF52br0qRQsOfcY4+owD8kwcdhmYsCXA=; b=CYcfMeY/vMSAtohHBNyKkWcJL5hp6gnbdv2cDWNNyHKZ4BxmOjWJI99JLEMHNTcrPd f9B81eOn5EnPvUX/1TkpAB1fCe9Xw7mSIhkg5/doucSI7FhFFLKJ8QgOXiIk5YytHjRH mSOvVqyNDY8+QtYej/kQKKYnhZDRlRXZyuewI8w3ENvWV7wop+pwy1NhSc3WD89UMrBo FnSrnMB4JhiI2l92qyBEXeYRBJKBnefSi/IOc3X9noBE0M7ypPazxt1sV50/rWghUn5E /S10Nk8stKno0UPHnT9c410EhKjuamjAwapfRXQ1GqMPPDB9xgWGHypjIbBp+EjI4Arz ilmg== X-Forwarded-Encrypted: i=1; AFNElJ8dDk4ig3vBKSTKVX81epal6bHC0PwJrpCpCl1GcV6MvNx7feByFUidwvJea0q3axoLFvNxuMuqSUTfHig=@vger.kernel.org X-Gm-Message-State: AOJu0YwG0Pt+f+GUI7T381VdpkyWzuOohtcYcdGRCCXWKkM2hAhst2Qd 1IjMiJujQw307bXX8kkp+PO6Wxu7lRlZ79FyK6sjZ1d1KaTDdf27cphx X-Gm-Gg: Acq92OE/qz7e9o4Ht203BkQbTWptr2Y5B4/97Gfv4JrBni0O5NxiPneuiB/bOCFG1JR F7/rv4y/Glksilmt7dUUyw3M1KyY6XWo67TUUBOBc/pRlldx89S2UqBDSvoD/AB58P8YWY/mimU 3bSOS0K0SmjuCoI+fdGJ+s4Fkad1ICnppM0LrtdqV2Wn9jzs29IIO9Pgr0oGQNj9ElIR08+G1pZ Nfebr//JhufHi4sPScptf7SU5zBzdKW+KLqRj2OP35QffSWmLRNijgWPuWQSaZckh4dMEe59PwY Q2efv2Y1XwD+mG5t3EPkyRh70aqZ/vvQDnAB96RXYFsGpibjmrARsd9DwmS6M8ovyecGsPwN/cq UilsMT9oS9ZHKwt80YhNm7ozsB3LlX9EKxPVOjnHiko/RZlMIuknW5kezHugfHbwMC4nb1LmsN5 U5/aEbP/yWtQGu1EsxytCNTTpNRi03HlaUa3iF4YBB6bgqC5hqmfTgEyMhhB5vVBnyR5EzRliPs a6uQAM= X-Received: by 2002:a05:600d:6447:10b0:48f:d5b8:5b07 with SMTP id 5b1f17b1804b1-490426c5b1emr200251675e9.20.1779775322583; Mon, 25 May 2026 23:02:02 -0700 (PDT) Received: from localhost.localdomain ([188.27.64.216]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-490454b7d57sm295929035e9.15.2026.05.25.23.01.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 25 May 2026 23:02:01 -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 Subject: [RFC PATCH net] netfilter: flowtable: fix offloaded ct timeout never being extended Date: Tue, 26 May 2026 09:01:38 +0300 Message-ID: <20260526060138.3924-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. Compare against the current ct->timeout value instead. This patch is sent as RFC: the diagnosis is verified on hardware and the fix resolves the drop, but review of the chosen approach is welcome. Fixes: 03428ca5cee9 ("netfilter: conntrack: rework offload nf_conn timeout = extension logic") Signed-off-by: Adrian Bente --- net/netfilter/nf_flow_table_core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/net/netfilter/nf_flow_table_core.c +++ b/net/netfilter/nf_flow_table_core.c @@ -541,8 +541,10 @@ * after this -- is fine, datapath is authoritative. */ if (new_timeout) { + u32 old =3D READ_ONCE(ct->timeout); + new_timeout +=3D nfct_time_stamp; - cmpxchg(&ct->timeout, expires, new_timeout); + cmpxchg(&ct->timeout, old, new_timeout); } } =20 --=20 2.46.0