netdev - Re: [PATCH ethtool-next] netlink: tsconfig: add HW time stamping configuration

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20251029153812.10bd6397@kernel.org>
Date: Wed, 29 Oct 2025 15:38:12 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Vadim Fedorenko <vadim.fedorenko@...ux.dev>
Cc: Michal Kubecek <mkubecek@...e.cz>, netdev@...r.kernel.org, Kory Maincent
 <kory.maincent@...tlin.com>
Subject: Re: [PATCH ethtool-next] netlink: tsconfig: add HW time stamping
 configuration

On Wed, 29 Oct 2025 18:53:20 +0000 Vadim Fedorenko wrote:
> >> Well, yes, it's only 1 bit is supposed to be set. Unfortunately, netlink
> >> interface was added this way almost a year ago, we cannot change it
> >> anymore without breaking user-space API.  
> > 
> > The netlink interface only mirrors what we already had in struct
> > ethtool_ts_info (i.e. the ioctl interface). Therefore my question was
> > not really about this part of kernel API (which is fixed already) but
> > rather about the ethtool command line syntax.
> > 
> > In other words, what I really want to ask is: Can we be absolutely sure
> > that it can never possibly happen in the future that we might need to
> > set more than one bit in a set message?
> > 
> > If the answer is positive, I'm OK with the patch but perhaps we should
> > document it explicitly in the TSCONFIG_SET description in kernel file
> > Documentation/networking/ethtool-netlink.rst  
> 
> Well, I cannot say about long-long future, but for the last decade we
> haven't had a need for multiple bits to be set up. I would assume that
> the reality will be around the same.
> 
> Jakub/Kory do you have thoughts?

hard to prove a negative, is the question leading to a different
argument format which will let us set multiple bits? Looks like
we could potentially allow specifying tx / rx-filter multiple
times? Or invent new keywords for the extra bits which presumably 
would be somehow orthogonal to filtering?

tl;dr I'm unclear on the exact concern..