From: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
To: Vadim Fedorenko <vadim.fedorenko@linux.dev>,
Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Cc: Willem de Bruijn <willemdebruijn.kernel@gmail.com>,
Willem de Bruijn <willemb@google.com>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>,
"David S. Miller" <davem@davemloft.net>,
"Loktionov, Aleksandr" <aleksandr.loktionov@intel.com>,
Kurt Kanzenbach <kurt@linutronix.de>,
"Nguyen, Anthony L" <anthony.l.nguyen@intel.com>,
"Kitszel, Przemyslaw" <przemyslaw.kitszel@intel.com>,
Paul Menzel <pmenzel@molgen.mpg.de>,
"Gomes, Vinicius" <vinicius.gomes@intel.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
Richard Cochran <richardcochran@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Andrew Lunn <andrew+netdev@lunn.ch>,
"intel-wired-lan@lists.osuosl.org"
<intel-wired-lan@lists.osuosl.org>,
"Keller, Jacob E" <jacob.e.keller@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-next v3] igb: Retrieve Tx timestamp directly from interrupt for i210
Date: Mon, 09 Feb 2026 07:46:01 -0500 [thread overview]
Message-ID: <willemdebruijn.kernel.2e6213a98660b@gmail.com> (raw)
In-Reply-To: <78e2af2c-40e6-43f1-9471-42f350e69389@linux.dev>
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 acceptable
> >>>>>>> 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_NET_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…
> >>
> >> Looks like you are mixing things. SIOCSHWTSTAMP/ndo_hwtstamp_set are HW
> >> configuration calls while OPT_TSONLY is socket option, which is setup 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 but
> > 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 of
> 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 be
> 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.
next prev parent reply other threads:[~2026-02-09 12:46 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-05 7:54 [PATCH iwl-next v3] igb: Retrieve Tx timestamp directly from interrupt for i210 Kurt Kanzenbach
2026-02-05 9:47 ` [Intel-wired-lan] " Loktionov, Aleksandr
2026-02-05 10:03 ` Sebastian Andrzej Siewior
2026-02-05 10:37 ` Loktionov, Aleksandr
2026-02-05 10:52 ` Sebastian Andrzej Siewior
2026-02-05 11:56 ` Vadim Fedorenko
2026-02-05 14:51 ` Sebastian Andrzej Siewior
2026-02-05 16:27 ` Vadim Fedorenko
2026-02-05 16:43 ` Sebastian Andrzej Siewior
2026-02-05 16:48 ` Vadim Fedorenko
2026-02-05 21:41 ` Willem de Bruijn
2026-02-06 7:44 ` Sebastian Andrzej Siewior
2026-02-06 10:12 ` Vadim Fedorenko
2026-02-08 16:25 ` Willem de Bruijn
2026-02-09 9:06 ` Sebastian Andrzej Siewior
2026-02-09 10:43 ` Vadim Fedorenko
2026-02-09 11:48 ` Sebastian Andrzej Siewior
2026-02-09 12:24 ` Vadim Fedorenko
2026-02-09 12:46 ` Willem de Bruijn [this message]
2026-02-10 12:12 ` Sebastian Andrzej Siewior
2026-02-10 16:14 ` Willem de Bruijn
2026-02-11 12:08 ` Kurt Kanzenbach
2026-02-11 16:29 ` Willem de Bruijn
2026-02-12 18:33 ` Sebastian Andrzej Siewior
2026-02-14 23:26 ` Sebastian Andrzej Siewior
2026-02-11 18:54 ` Jakub Kicinski
2026-02-12 16:28 ` Sebastian Andrzej Siewior
2026-02-11 19:29 ` Jacob Keller
2026-02-11 21:44 ` Jakub Kicinski
2026-02-12 16:47 ` Sebastian Andrzej Siewior
2026-02-05 11:58 ` Kurt Kanzenbach
2026-02-05 12:20 ` Loktionov, Aleksandr
2026-02-06 0:05 ` Jacob Keller
2026-02-05 12:12 ` Sebastian Andrzej Siewior
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=willemdebruijn.kernel.2e6213a98660b@gmail.com \
--to=willemdebruijn.kernel@gmail.com \
--cc=aleksandr.loktionov@intel.com \
--cc=andrew+netdev@lunn.ch \
--cc=anthony.l.nguyen@intel.com \
--cc=bigeasy@linutronix.de \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jacob.e.keller@intel.com \
--cc=kuba@kernel.org \
--cc=kurt@linutronix.de \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=pmenzel@molgen.mpg.de \
--cc=przemyslaw.kitszel@intel.com \
--cc=richardcochran@gmail.com \
--cc=vadim.fedorenko@linux.dev \
--cc=vinicius.gomes@intel.com \
--cc=willemb@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox