netdev - Re: [PATCH net-next] rtnetlink: extend RTEXT_FILTER_SKIP_STATS to IFLA_VF

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 14 Jun 2023 11:03:17 +0200
From: Paolo Abeni <pabeni@...hat.com>
To: "Keller, Jacob E" <jacob.e.keller@...el.com>, Gal Pressman
 <gal@...dia.com>,  Stephen Hemminger <stephen@...workplumber.org>
Cc: "David S. Miller" <davem@...emloft.net>, Jakub Kicinski
 <kuba@...nel.org>,  David Ahern <dsahern@...il.com>, Michal Kubecek
 <mkubecek@...e.cz>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 Edwin Peer <edwin.peer@...adcom.com>, Edwin Peer <espeer@...il.com>
Subject: Re: [PATCH net-next] rtnetlink: extend RTEXT_FILTER_SKIP_STATS to
 IFLA_VF_INFO

On Mon, 2023-06-12 at 05:34 +0000, Keller, Jacob E wrote:
> > -----Original Message-----
> > From: Gal Pressman <gal@...dia.com>
> > Sent: Sunday, June 11, 2023 10:59 AM
> > To: Stephen Hemminger <stephen@...workplumber.org>
> > Cc: David S. Miller <davem@...emloft.net>; Jakub Kicinski <kuba@...nel.org>;
> > David Ahern <dsahern@...il.com>; Michal Kubecek <mkubecek@...e.cz>;
> > netdev@...r.kernel.org; Edwin Peer <edwin.peer@...adcom.com>; Edwin Peer
> > <espeer@...il.com>
> > Subject: Re: [PATCH net-next] rtnetlink: extend RTEXT_FILTER_SKIP_STATS to
> > IFLA_VF_INFO
> > 
> > On 11/06/2023 18:06, Stephen Hemminger wrote:
> > 
> > > Better but it is still possible to create too many VF's that the response
> > > won't fit.
> > 
> > Correct, no argues here.
> > It allowed me to see around ~200 VFs instead of ~70, a step in the right
> > direction.
> 
> I remember investigating this a few years ago and we hit limits of ~200 that were essentially unfixable without creating a new API that can separate the reply over more than one message. The VF info data was not designed in the current op to allow processing over multiple messages. It also (unfortunately) doesn't report errors so it ends up just truncating instead of producing an error.
> 
> Fixing this completely is non-trivial.

As it looks like the is substantial agreement on this approach being a
step in the right direction and I can't think of anything better, I
suggest to merge this as is, unless someone voices concerns very soon,
very loudly.

Thanks!

Paolo