From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) (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 A590C426D05 for ; Thu, 5 Feb 2026 15:52:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.65 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770306752; cv=none; b=T/4z8N6J/sTSo4iaHWlDGz6LiErYfVqLSDrMGMLpis598mvReXl4Vdxqd6lEG9Rr2aPAqQUUk5YoO2nEe7KG1okmJNobCXI4G8wA5of6n4r/FEd3UXJxwqY0VLLzmDfFQCCRqhCjNZwwFkDATYSOr2aBh9oNfMP7twxkbkAoJdA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770306752; c=relaxed/simple; bh=FNFL0/+E2aKnOvoNT9LImHUIIlRjvKZVxcmxb7yxYDI=; h=Mime-Version:Content-Type:Date:Message-Id:Cc:Subject:From:To: References:In-Reply-To; b=Za4TWhpFe6hsNWxi3QOM8eOjavtnr6bQ2CSOCv/yK1EoOwOHxipq2YHUYiXExTvV6lfsJFmyUjh6anEterKoWv2FsOABw2wTnfHyw7wLJUNj5TyVtWRW9Y+iFxSANz9eDtebeIA4C3kv5G1cczRkSWYryf+zKfiiLGXCODH2c3o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cloudflare.com; spf=pass smtp.mailfrom=cloudflare.com; dkim=pass (2048-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b=NsdhnNmZ; arc=none smtp.client-ip=209.85.128.65 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=cloudflare.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=cloudflare.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=cloudflare.com header.i=@cloudflare.com header.b="NsdhnNmZ" Received: by mail-wm1-f65.google.com with SMTP id 5b1f17b1804b1-47ee3a63300so11995625e9.2 for ; Thu, 05 Feb 2026 07:52:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google09082023; t=1770306750; x=1770911550; darn=vger.kernel.org; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=UTu7qU8UN7vo13iwk65Itm5Hd0Cv+O0GXDEO+OULSSA=; b=NsdhnNmZZ+or54k3tuyagYkH2oSUJVSQZusPjtXF0o9co4Yavd9/67+CVje6lfG2GH Imm7ruzWxwyorDgaPrNf8XDPNEE5ga3JGo2ASBTBTjhKyJcfNnvRvwRtN5SuGLyuhabv S9o+pymxhEWJBc7Xkt7vYF+Nvd1YmnaIv3dEfm6XCXyFjvBRocdIRwxwJQdJOb4nAr76 DJJ/6AdIYYeNxkfSL4nn2cwmbfJRP3SydAlttMcCVmbksCdxZ1/Pd5e1k/W9xcIghZRZ dKglZ5nT67KNqyF7e0tLcJn6w/3Eq6yiXiGxV7e777R8p8qgwuGOZvSil5zYcQLet7ar cCWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770306750; x=1770911550; h=in-reply-to:references:to:from:subject:cc:message-id:date :content-transfer-encoding:mime-version:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=UTu7qU8UN7vo13iwk65Itm5Hd0Cv+O0GXDEO+OULSSA=; b=u3//MpkPUll8XRBqjoM7Rfe7BWLpK17pNVuiwSpZhYSXsnGm3+QvFBoa5Bar7uOIRu EpyaMmU7CgbY9JGqZBha37XTmADZH85kLHYazUtaUUOw6AdQPg8z0Y1v+E6W7lc6kFI6 CvL5ElnBfXuSEKxKejYv5W+bn6R4oNP7WiU3Qxrp1xtMolcgwUl5Zv8J1RgJtkQzZPkO /YWD4uBk2IEYJ+AZAiQsdBmAbPn82Y/ft1zMIdME9fnvTSUzba5ArsDC5jafWbB5rp2+ +oBrmLe/gtkBqZm/JVMiuFJIqxp46Dyl1fN9HrbvRzhYUOaNQVZSL308aMdRwEyJ9HfI e5sQ== X-Forwarded-Encrypted: i=1; AJvYcCU3PSXSqNy1Eb1A9Y3WImohy5NZY8MBf4p+N4/7K8/frRuJnbPqcL+sSQMh/qrgp423dr2cXs8=@vger.kernel.org X-Gm-Message-State: AOJu0Yw3+mdC7m4O3w+w9OnRoc+7ZZfNS+BU64puFgkicdLr7GJjJKsg 26qdVOD33N6p9EFEJKpHkHOJpV8bWkgbWeKKaoim2DJ5L6s+05Dddzkn0fC6Out0ejU= X-Gm-Gg: AZuq6aJw5BDV+hiRQZkRjpIcJZ/hBdRi10pc8nrilzxAN46ykPFOHScu+PWITieRjfk vNYsDx4/6i2BTqar7atkIVq9nnl8zaRcwHIpSE5c9RUI1C7B7tvKoNHtQ96K0tcPpBxy6rmM5Sg 0WrX9GU2a1al5g+bu08e13SKlgE22MYjKPTlh8Vfp5vh46CJS7ux3UrEPyrUuCpk3DoV+ck1XLe ow+BbNJG9rGClgZO3p7KYsfzRC8nIE/3cV9vpbqW6PxIXJErAQ7eKA3wbC/k9591yl5baOlCOeM xWz40nE5bmD/7md4ebw+p1f9BIUap9jSre4hS24K2PnHtjWQhnP2PqWNYPGkTRzgZOLa0Mg/vZ4 tRs6DiQSLbrT36h6ONRRnYSVBym9hjyTSlo0XGTBtgesLxHmpOF71bFJDNXVgTagzu+z87flDeQ == X-Received: by 2002:a05:600c:810b:b0:480:4a90:1af2 with SMTP id 5b1f17b1804b1-4830e979f7bmr95259165e9.35.1770306750051; Thu, 05 Feb 2026 07:52:30 -0800 (PST) Received: from localhost ([2a09:bac5:327b:2541::3b6:79]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-436234781fbsm5263375f8f.15.2026.02.05.07.52.28 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Feb 2026 07:52:29 -0800 (PST) Precedence: bulk X-Mailing-List: netdev@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 Date: Thu, 05 Feb 2026 16:52:27 +0100 Message-Id: Cc: , , , , , , , , , , , , , , , , , , , , , , , , Subject: Re: [PATCH bpf-next] bpf: Allow bpf_tcp_sock() helper in XDP From: "Arthur Fabre" To: "Martin KaFai Lau" X-Mailer: aerc 0.17.0 References: <20260204-afabre-bpf_tcp_sock-v1-1-a22b40c630c0@cloudflare.com> <167a8f4235973cd42372884aa66182a10fd17e50c70626b1fa0e659933e82b4e@mail.kernel.org> <917eadc0-9341-48d5-a795-8a7d5318886c@linux.dev> In-Reply-To: <917eadc0-9341-48d5-a795-8a7d5318886c@linux.dev> On Wed Feb 4, 2026 at 11:27 PM CET, Martin KaFai Lau wrote: > > > On 2/4/26 5:04 AM, bot+bpf-ci@kernel.org wrote: > >> But the TCP TIME-WAIT state needs special handling for this: pack= ets > >> received for a TIME-WAIT socket can either belong to the current > >> incarnation of the connection, or a new incarnation. The only way= to > >> determine this is to compare the sequence numbers. > >> > >> Add the bpf_tcp_sock() helper in XDP to allow the socket sequence > >> numbers to be read. > >=20 > > Can this approach work for TIME-WAIT sockets? Looking at bpf_tcp_sock()= in > > net/core/filter.c: > >=20 > > if (sk_fullsock(sk) && sk->sk_protocol =3D=3D IPPROTO_TCP) > > return (unsigned long)sk; > > return (unsigned long)NULL; > >=20 > > And sk_fullsock() in include/net/sock.h: > >=20 > > static inline bool sk_fullsock(const struct sock *sk) > > { > > return (1 << sk->sk_state) & ~(TCPF_TIME_WAIT | TCPF_NEW_SYN_R= ECV); > > } > >=20 > > TIME-WAIT sockets are explicitly excluded by sk_fullsock(), so bpf_tcp_= sock() > > returns NULL for them. The sequence numbers stored in TIME-WAIT sockets > > (skc_tw_rcv_nxt and skc_tw_snd_nxt in sock_common) would not be accessi= ble > > through this helper. > >=20 > > The change itself is useful for accessing tcp_sock fields from establis= hed > > connections in XDP, but the commit message implies this solves the TIME= -WAIT > > sequence number problem described, which doesn't appear to be the case. > > or use "tp =3D bpf_core_cast(sk, struct tcp_sock /* or tcp_timewait_sock= =20 > */);". The bpf prog can also read all members of the kernel struct=20 > instead of a subset defined in bpf_tcp_sock. Brilliant, that works! Thanks Martin. > > pw-bot: cr > > >=20 > >=20 > > --- > > AI reviewed your patch. Please fix the bug or email reply why it's not = a bug. > > See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/REA= DME.md > >=20 > > CI run summary: https://github.com/kernel-patches/bpf/actions/runs/2167= 1977729 > >=20 > > AI-authorship-score: low > > AI-authorship-explanation: The commit message style is consistent with = human-written kernel patches, with natural technical language and standard = formatting; the technical error is more likely human oversight than AI hall= ucination. > > issues-found: 1 > > issue-severity-score: low > > issue-severity-explanation: The issue is a misleading commit message th= at claims the change enables TIME-WAIT socket sequence number reading, but = the bpf_tcp_sock() helper explicitly returns NULL for TIME-WAIT sockets.