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: <e53db011-fe6a-4e63-b740-a7d2ff33dfa9@intel.com>
Date: Mon, 8 Jul 2024 11:51:47 +0200
From: Alexander Lobakin <aleksander.lobakin@...el.com>
To: Willem de Bruijn <willemdebruijn.kernel@...il.com>
CC: "David S. Miller" <davem@...emloft.net>, Eric Dumazet
	<edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
	<pabeni@...hat.com>, David Ahern <dsahern@...nel.org>, Xuan Zhuo
	<xuanzhuo@...ux.alibaba.com>, Andrew Lunn <andrew@...n.ch>,
	<nex.sw.ncis.osdt.itp.upstreaming@...el.com>, <netdev@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next v2 3/5] netdev_features: convert NETIF_F_LLTX to
 dev->lltx

From: Willem De Bruijn <willemdebruijn.kernel@...il.com>
Date: Sat, 06 Jul 2024 09:29:37 -0400

> Alexander Lobakin wrote:
>> NETIF_F_LLTX can't be changed via Ethtool and is not a feature,
>> rather an attribute, very similar to IFF_NO_QUEUE (and hot).
>> Free one netdev_features_t bit and make it a "hot" private flag.
>>
>> Signed-off-by: Alexander Lobakin <aleksander.lobakin@...el.com>

[...]

>> @@ -23,8 +23,6 @@ enum {
>>  	NETIF_F_HW_VLAN_CTAG_FILTER_BIT,/* Receive filtering on VLAN CTAGs */
>>  	NETIF_F_VLAN_CHALLENGED_BIT,	/* Device cannot handle VLAN packets */
>>  	NETIF_F_GSO_BIT,		/* Enable software GSO. */
>> -	NETIF_F_LLTX_BIT,		/* LockLess TX - deprecated. Please */
>> -					/* do not use LLTX in new drivers */
>>  	NETIF_F_NETNS_LOCAL_BIT,	/* Does not change network namespaces */
>>  	NETIF_F_GRO_BIT,		/* Generic receive offload */
>>  	NETIF_F_LRO_BIT,		/* large receive offload */
> 
>> @@ -1749,6 +1749,8 @@ enum netdev_reg_state {
>>   *			booleans combined, only to assert cacheline placement
>>   *	@priv_flags:	flags invisible to userspace defined as bits, see
>>   *			enum netdev_priv_flags for the definitions
>> + *	@lltx:		device supports lockless Tx. Mainly used by logical
>> + *			interfaces, such as tunnels
> 
> This loses some of the explanation in the NETIF_F_LLTX documentation.
> 
> lltx is not deprecated, for software devices, existing documentation
> is imprecise on that point. But don't use it for new hardware drivers
> should remain clear.

It's still written in netdevices.rst. I rephrased that part as
"deprecated" is not true.
If you really think this may harm, I can adjust this one.

> 
>>   *
>>   *	@name:	This is the first field of the "visible" part of this structure
>>   *		(i.e. as seen by users in the "Space.c" file).  It is the name
> 
>> @@ -3098,7 +3098,7 @@ static void amt_link_setup(struct net_device *dev)
>>  	dev->hard_header_len	= 0;
>>  	dev->addr_len		= 0;
>>  	dev->priv_flags		|= IFF_NO_QUEUE;
>> -	dev->features		|= NETIF_F_LLTX;
>> +	dev->lltx		= true;
>>  	dev->features		|= NETIF_F_GSO_SOFTWARE;
>>  	dev->features		|= NETIF_F_NETNS_LOCAL;
>>  	dev->hw_features	|= NETIF_F_SG | NETIF_F_HW_CSUM;
> 
> Since this is an integer type, use 1 instead of true?

I used integer type only to avoid reading new private flags byte by byte
(bool is always 1 byte) instead of 4 bytes when applicable.
true/false looks more elegant for on/off values than 1/0.

> 
> Type conversion will convert true to 1. But especially when these are
> integer bitfields, relying on conversion is a minor unnecessary risk.

Any examples when/where true can be non-1, but something else, e.g. 0?
Especially given that include/linux/stddef.h says this:

enum {
	false	= 0,
	true	= 1
};

No risk here. Thinking that way (really sounds like "are you sure NULL
is always 0?") would force us to lose lots of stuff in the kernel for no
good.

> 
>>  int dsa_user_suspend(struct net_device *user_dev)
>> diff --git a/net/ethtool/common.c b/net/ethtool/common.c
>> index 6b2a360dcdf0..44199d1780d5 100644
>> --- a/net/ethtool/common.c
>> +++ b/net/ethtool/common.c
>> @@ -24,7 +24,6 @@ const char netdev_features_strings[NETDEV_FEATURE_COUNT][ETH_GSTRING_LEN] = {
>>  	[NETIF_F_HW_VLAN_STAG_FILTER_BIT] = "rx-vlan-stag-filter",
>>  	[NETIF_F_VLAN_CHALLENGED_BIT] =  "vlan-challenged",
>>  	[NETIF_F_GSO_BIT] =              "tx-generic-segmentation",
>> -	[NETIF_F_LLTX_BIT] =             "tx-lockless",
>>  	[NETIF_F_NETNS_LOCAL_BIT] =      "netns-local",
>>  	[NETIF_F_GRO_BIT] =              "rx-gro",
>>  	[NETIF_F_GRO_HW_BIT] =           "rx-gro-hw",
> 
> Is tx-lockless no longer reported after this?
> 
> These features should ideally still be reported, even if not part of

Why do anyone need tx-lockless in the output? What does this give to the
users? I don't believe this carries any sensible/important info.

> the features bitmap in the kernel implementation.
> 
> This removal is what you hint at in the cover letter with
> 
>   Even shell scripts won't most likely break since the removed bits
>   were always read-only, meaning nobody would try touching them from
>   a script.
> 
> It is a risk. And an avoidable one?

What risk are you talking about? Are you aware of any scripts or
applications that want to see this bit in Ethtool output? I'm not.

Thanks,
Olek

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ