netdev - Re: [PATCH net-next v2 1/8] devlink: Introduce PCI SF port flavour and port attribute

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]

Date:   Fri, 18 Sep 2020 22:49:16 -0600
From:   David Ahern <dsahern@...il.com>
To:     Parav Pandit <parav@...dia.com>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>
Cc:     Jiri Pirko <jiri@...dia.com>
Subject: Re: [PATCH net-next v2 1/8] devlink: Introduce PCI SF port flavour
 and port attribute

On 9/18/20 10:13 AM, Parav Pandit wrote:
>> You keep adding patches that extend the template based names. Those are
>> going to cause odd EINVAL failures (the absolute worst kind of configuration
>> failure) with no way for a user to understand why the command is failing, and
>> you need to handle that. Returning an extack message back to the user is
>> preferred.
> Sure, make sense.
> I will run one short series after this one, to return extack in below code flow and other where extack return is possible.
> In sysfs flow it is irrelevant anyway.

yes, sysfs is a different problem.

> rtnl_getlink()
>   rtnl_phys_port_name_fill()
>      dev_get_phys_port_name()
>        ndo_phys_port_name()
> 
> is that ok?

sure. The overflow is not going to happen today with 1-10 SFs; but you
are pushing ever close to the limit hence the push.


> This series is not really making phys_port_name any worse except that sfnum field width is bit larger than vfnum.
> 
> Now coming back to phys_port_name not fitting in 15 characters which can trigger -EINVAL error is very slim in most sane cases.
> Let's take an example.
> A controller in valid range of 0 to 16,
> PF in range of 0 to 7,
> VF in range of 0 to 255,
> SF in range of 0 to 65536,
> 
> Will generate VF phys_port_name=c16pf7vf255 (11 chars + 1 null)
> SF phys_port name = c16pf7sf65535 (13 chars + 1 null)
> So yes, eth dev name won't fit in but phys_port_name failure is almost nil.
> 

You lost me on that last sentence. Per your example for SF, adding 'eni'
or 'eth' as a prefix (which you commonly use in examples and which are
common prefixes) to that name and you overflow the IFNAMESZ limit.


(understand about the systemd integration and appreciate the forward
thinking about that).