netdev - Re: [PATCH net-next v5 1/2] ethtool: add speed/duplex validation functions

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: <56B38AA6.9050307@hpe.com>
Date:	Thu, 4 Feb 2016 09:30:14 -0800
From:	Rick Jones <rick.jones2@....com>
To:	"Michael S. Tsirkin" <mst@...hat.com>
Cc:	Stephen Hemminger <stephen@...workplumber.org>,
	Nikolay Aleksandrov <razor@...ckwall.org>,
	netdev@...r.kernel.org, roopa@...ulusnetworks.com,
	davem@...emloft.net,
	Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
	linux-api@...r.kernel.org
Subject: Re: [PATCH net-next v5 1/2] ethtool: add speed/duplex validation
 functions

On 02/04/2016 04:47 AM, Michael S. Tsirkin wrote:
> On Wed, Feb 03, 2016 at 03:49:04PM -0800, Rick Jones wrote:
>> And even for not-quite-virtual devices - such as a VC/FlexNIC in an HPE
>> blade server there can be just about any speed set.  I think we went down a
>> path of patching some things to address that many years ago.  It would be a
>> shame to undo that.
>>
>> rick
>
> I'm not sure I understand. The question is in defining the UAPI.
> We currently have:
>
>   * @speed: Low bits of the speed
>   * @speed_hi: Hi bits of the speed
>
> with the assumption that all values come from the defines.
>
> So if we allow any value here we need to define what it means.

I may be mixing apples and kiwis.  Many years ago when HP came-out with 
their blades and VirtualConnect, they included the ability to create 
"flex NICs" - "sub-NICs" out of a given interface port on a blade, and 
to assign each a specific bitrate in increments (IIRC) of 100 Mbit/s. 
This was reported up through the driver and it became necessary to make 
ethtool (again, IIRC) not so picky about "valid" speed values.

rick