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
| ||
|
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.
Powered by blists - more mailing lists