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 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:   Sat, 19 Sep 2020 05:35:57 +0000
From:   Parav Pandit <parav@...dia.com>
To:     David Ahern <dsahern@...il.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



> From: David Ahern <dsahern@...il.com>
> Sent: Saturday, September 19, 2020 10:19 AM
> 
> 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.
> 
Ok. yeah. got it.
> 
> > 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.
>
Right. Got you.
Will run short series for returning extack.
 
> 
> (understand about the systemd integration and appreciate the forward thinking
> about that).
Thank you David.