From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f173.google.com (mail-yw1-f173.google.com [209.85.128.173]) (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 2AA3A2116F6 for ; Mon, 9 Feb 2026 12:46:04 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.173 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770641165; cv=none; b=R5v5PLCwUybyGekmcF+mrcobFgYP6hgjfHcTGJnYMWWTghkDb/1U9hg8jschU+iH7UmgKqXyKHr4RvDDCuRJ4io7ZAG1PoFvw38dTucV7eA0rkzY9BF48z/owg8lrQG0uWv0TxNcm4xXt9aS/F3EBudQTMuDlug09xbncVTRqiI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770641165; c=relaxed/simple; bh=QlrEMA6U+xP0E3BuDUykUYlfoN4reTbUOv4b0PXeCW4=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=aDeJt2haPBHrtK8J5CbkJJgoVSUfwj/RoZ2Qo4l2MV2Mv3gyrXsN6VB8C7HIlUitn7bqIhI8saxf4sEkTCP/HX8xBzB1DJiLgoU7skefW8hfh2+zwWk7ZHanSgv2t5ZLjS76NUmAdNBFrW6VPF4Z2VpPKGt9y9AS1sFjcA/1OiA= 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=ctvlRnJa; arc=none smtp.client-ip=209.85.128.173 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="ctvlRnJa" Received: by mail-yw1-f173.google.com with SMTP id 00721157ae682-79430ef54c3so25509387b3.2 for ; Mon, 09 Feb 2026 04:46:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1770641164; x=1771245964; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=QlrEMA6U+xP0E3BuDUykUYlfoN4reTbUOv4b0PXeCW4=; b=ctvlRnJaBGTYyijkPspIA3jpfq040CcQLWRngSawv4YWnk0P6zZ787ykQ2f4jeyiIs /2IqAMffIvSuZiTKVDPwQBCyG1eV5lrCuB1CkxTmWbfG7nYsTlkl8aEms1/H3q5t59OG ydXB9QClnvk2WacTsmdnz46cMRi1RzQRgYK6Yoqp4S2oI1CFVY6maNvCY09ly+ra7hH6 kfsGd3iSjc+Pi3DzGzvkH0X6aSl1tJFq0SAwbQU8UZs1BWojWXNtQCzrfOd1ZFIZYLIZ yE8Wzx7mgK5lSGKo38lt1RR7jmQWH39HZAuWoBdD0zHW7DsgSjq/NuBjy0Fwqqx1pXJJ L8gQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1770641164; x=1771245964; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=QlrEMA6U+xP0E3BuDUykUYlfoN4reTbUOv4b0PXeCW4=; b=KWr4HQWlTuL+DqTIoiwzGHJ6fBqgctZRMBFzJnFkYR1QI4j79MRiYt3R1T3tiLDS3k 3AE3m3maB9VHaVOlwtnwUjpr2b+iXU/A2Ljj/slq7zjicS8bYdYT4WIG5bxhV9yiXGav zC+FF/Q+uQs6A1DsDk4ywH6BBUZoZw3GHpTEp0qh4S/5kdr3881abxYRvOQuVvMrSul4 UfiTnpXBfsRBPxjAAnrfDIPx1FDknR9Bl0HXQAmyEr3z7SUbJsMi9EE+IU2WEjECYSbG yd3yVzj10kQHrELic5fCY5Yf+ANxG8TF7bs9f4wJvvqAn6BfehPPx3vAFvnTqnFjMwmv vTqg== X-Forwarded-Encrypted: i=1; AJvYcCV7KhfPdZIQIMgnjY8RrNY76zMjMuzyswPFTbXuYR3s2JmF55eQEbxp/6X6rdh+T5r2Bw5hDNivcuRSBtk=@vger.kernel.org X-Gm-Message-State: AOJu0YxUfVyDYJ+BpaDwWWW/YsVvClBrsTj4OTHM07W6hGDj/07kzfcL Ke86e9QNWqC9aWSQykW0Quow2Ax9CWt9L9w+s1JJBI+MjIxaI6LBxCTl X-Gm-Gg: AZuq6aLNcbvsgyV9m6r1LnQIbFEiM48Uq1v3rVKZgqLfB2ztswTypYcQwUbtkd69CfN eDNRtgx2LdlmWjkV7w7mFSc4MZLFfBPR2wA+5TD5mR1zcTZlJnW1OjEpzQfRYHwMC3JCBYviI8Y wol8ZalExsLYXMw84QkCUcyyEtGDwjt3mZycEmIfVh0gdlnuC5RBCg5vAauigKFDP6mccStGP80 qcIIl6eruHrKjDLDw41gz3L+ut2d+f6MlaQ1wkXRbo3zRseQ194uwp3bGOc+IIazofPt13Lctl1 ah26F7mFHrc83Z+i00/iZMsHpbdILCU0Vj6s84TUQERQn0l7sAHdDnOrr37qcc+Ux3u7VCMZOCP 72ggWmfPNeO9jBiI+8aIi79gRAqlw8RdKjxkz/2rWPiXRCZwoYQ9Ys5Qa972YYq/fmJW752iIbq kU5L0A2jL8OYvqf83YPz9A9pgJRRxyors0z4xxmaL42pFxhSLT6VRo7TjFFeW+7Ia7aTMbQg== X-Received: by 2002:a05:690c:9b0a:b0:794:a165:1c3b with SMTP id 00721157ae682-7952aab650dmr91143427b3.30.1770641163990; Mon, 09 Feb 2026 04:46:03 -0800 (PST) Received: from gmail.com (21.33.48.34.bc.googleusercontent.com. [34.48.33.21]) by smtp.gmail.com with UTF8SMTPSA id 00721157ae682-79529e45621sm91555017b3.0.2026.02.09.04.46.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 09 Feb 2026 04:46:03 -0800 (PST) Date: Mon, 09 Feb 2026 07:46:01 -0500 From: Willem de Bruijn To: Vadim Fedorenko , Sebastian Andrzej Siewior Cc: Willem de Bruijn , Willem de Bruijn , Jakub Kicinski , Paolo Abeni , Eric Dumazet , "David S. Miller" , "Loktionov, Aleksandr" , Kurt Kanzenbach , "Nguyen, Anthony L" , "Kitszel, Przemyslaw" , Paul Menzel , "Gomes, Vinicius" , "netdev@vger.kernel.org" , Richard Cochran , "linux-kernel@vger.kernel.org" , Andrew Lunn , "intel-wired-lan@lists.osuosl.org" , "Keller, Jacob E" Message-ID: In-Reply-To: <78e2af2c-40e6-43f1-9471-42f350e69389@linux.dev> References: <6a0f4cbb-e8b3-4f0e-b7f1-7f9ca5cba97d@linux.dev> <20260205145104.iWinkXHv@linutronix.de> <66925f09-ef9f-4401-baec-7d4c82a68ce3@linux.dev> <20260205164341.pJvni8kA@linutronix.de> <76acd5cc-eb6f-4c56-a5e6-f6413736afbb@linux.dev> <601f0c4b-52d8-4b60-96bf-f2d65f8073d8@linux.dev> <20260209090621.GiZqTiMJ@linutronix.de> <8e762437-69f9-40d7-bb75-3a45bef1d5d6@linux.dev> <20260209114836.GPU-vnnh@linutronix.de> <78e2af2c-40e6-43f1-9471-42f350e69389@linux.dev> Subject: Re: [Intel-wired-lan] [PATCH iwl-next v3] igb: Retrieve Tx timestamp directly from interrupt for i210 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Vadim Fedorenko wrote: > On 09/02/2026 11:48, Sebastian Andrzej Siewior wrote: > > On 2026-02-09 10:43:55 [+0000], Vadim Fedorenko wrote: > >> On 09/02/2026 09:06, Sebastian Andrzej Siewior wrote: > >>> On 2026-02-08 11:25:40 [-0500], Willem de Bruijn wrote: > >>>>>>> But it's more like a question to maintainers whether it is acce= ptable > >>>>>>> way of "fixing" drivers or it's no-go solution > >>>>>> > >>>>>> Requiring OPT_TSONLY unless CAP_NET_RAW would break legacy users= . > >>>>> > >>>>> Well, they are kinda broken already. Without OPT_TSONLY and CAP_N= ET_RAW all TX > >>>>> timestamps are silently dropped. > >>>> > >>>> Are you referring to sysctl_tstamp_allow_data? > >>>> > >>>> That is enabled by default. > >>> > >>> Yes. If so, then we don't need the check below which requires > >>> sk_callback_lock. > >>> > >>> Are SIOCSHWTSTAMP the legacy users or the ones which do not set > >>> OPT_TSONLY? > >>> > >>> I would suggest to move the CAP_NET_RAW check to the point where > >>> timestamping is getting enabled. > >>> Also if ndo_hwtstamp_set is the preferred method of getting things = done, > >>> I could check how many old ones are can be easily converted=E2=80=A6= > >> > >> Looks like you are mixing things. SIOCSHWTSTAMP/ndo_hwtstamp_set are= HW > >> configuration calls while OPT_TSONLY is socket option, which is setu= p via > >> setsockopt, you can find points searching for > >> SOF_TIMESTAMPING_OPT_TSONLY in the sources, basically > >> sock_set_timestamping() is the function to check > > = > > Yeah, but what is the legacy user here? If you enable HW-timestamps b= ut > > never set OPT_TSONLY and the sysctl is also 0 then you reply on the > > CAP_NET_RAW later on. Right? > = > Legacy users here means users of HW TX timestamps expecting full skb to= = > be returned back with the TX timestamp. Legacy here means that skb will= = > be returned with headers modified by stack, which is kind of exposure o= f > data, which requires CAP_NET_RAW... > = > > I just try to justify the CAP_NET_RAW check and if it is required to > > move it earlier (where HW timestamps are enabled). And if the sysctl > > check is enough then maybe it is not needed. > = > Capabilities should not change during lifetime of the process, should b= e > fine to move. On the other, sysctl can be changed system-wide which may= = > affect users. Ignore the hardware configuration. That is entirely optional. Some devices will timestamp every packet. The capability check here is per-socket, independent from the system hardware configuration. I don't see how it could be moved. Before OPT_TSONLY was introduced packets were always queued with their payload. The sysctl check was added to optionally disallow this. The check could arguably be moved earlier in the socket lifecycle and the decision cached in the socket. But then flipping the sysctl would not affect existing sockets, so that is a change in ABI behavior.