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: Windows password security audit tool. GUI, reports in PDF.

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

Date: Mon, 12 Jun 2023 05:34:14 +0000
From: "Keller, Jacob E" <jacob.e.keller@...el.com>
To: 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



> -----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:
> > On Sun, 11 Jun 2023 13:51:08 +0300
> > Gal Pressman <gal@...dia.com> wrote:
> >
> >> From: Edwin Peer <edwin.peer@...adcom.com>
> >>
> >> This filter already exists for excluding IPv6 SNMP stats. Extend its
> >> definition to also exclude IFLA_VF_INFO stats in RTM_GETLINK.
> >>
> >> This patch constitutes a partial fix for a netlink attribute nesting
> >> overflow bug in IFLA_VFINFO_LIST. By excluding the stats when the
> >> requester doesn't need them, the truncation of the VF list is avoided.
> >>
> >> While it was technically only the stats added in commit c5a9f6f0ab40
> >> ("net/core: Add drop counters to VF statistics") breaking the camel's
> >> back, the appreciable size of the stats data should never have been
> >> included without due consideration for the maximum number of VFs
> >> supported by PCI.
> >>
> >> Fixes: 3b766cd83232 ("net/core: Add reading VF statistics through the PF
> netdevice")
> >> Fixes: c5a9f6f0ab40 ("net/core: Add drop counters to VF statistics")
> >> Signed-off-by: Edwin Peer <edwin.peer@...adcom.com>
> >> Cc: Edwin Peer <espeer@...il.com>
> >> Signed-off-by: Gal Pressman <gal@...dia.com>
> >> ---
> >
> > 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.

Thanks,
Jake