netdev - Re: [PATCH net-next v2] ethtool: Clarify len/n

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 for Android: free password hash cracker in your pocket

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

Message-ID: <20260114193121.7366d02d@kernel.org>
Date: Wed, 14 Jan 2026 19:31:21 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Gal Pressman <gal@...dia.com>
Cc: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Andrew Lunn
 <andrew+netdev@...n.ch>, netdev@...r.kernel.org, Andrew Lunn
 <andrew@...n.ch>, Simon Horman <horms@...nel.org>, Dragos Tatulea
 <dtatulea@...dia.com>
Subject: Re: [PATCH net-next v2] ethtool: Clarify len/n_stats fields in/out
 semantics

On Wed, 14 Jan 2026 08:50:01 +0200 Gal Pressman wrote:
> On 14/01/2026 5:06, Jakub Kicinski wrote:
> > On Mon, 12 Jan 2026 13:57:08 +0200 Gal Pressman wrote:  
> >> --- a/include/uapi/linux/ethtool.h
> >> +++ b/include/uapi/linux/ethtool.h
> >> @@ -1101,6 +1101,13 @@ enum ethtool_module_fw_flash_status {
> >>   * Users must use %ETHTOOL_GSSET_INFO to find the number of strings in
> >>   * the string set.  They must allocate a buffer of the appropriate
> >>   * size immediately following this structure.
> >> + *
> >> + * Setting @len on input is optional (though preferred), but must be zeroed
> >> + * otherwise.
> >> + * When set, @len will return the requested count if it matches the actual
> >> + * count; otherwise, it will be zero.
> >> + * This prevents issues when the number of strings is different than the
> >> + * userspace allocation.  
> > 
> > Thanks the new text looks good, but we should also remove the 
> > "On return, the " from the field kdoc?  
> 
> I think it makes sense to keep.
> 
> The new text clarifies the in behavior, but the out behavior remains.

I'd interpret the "On return," as an indication that it's an output
only field. Not saying that's an intelligent interpretation, but it's
an existence proof. The uAPI comments should avoid ambiguity...