netdev - RE: [RFC PATCH] netlink: Increase netlink dump skb message size

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:	Wed, 27 Apr 2011 10:15:31 -0700
From:	"Rose, Gregory V" <gregory.v.rose@...el.com>
To:	Eric Dumazet <eric.dumazet@...il.com>,
	Steve Hodgson <shodgson@...arflare.com>
CC:	David Miller <davem@...emloft.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"bhutchings@...arflare.com" <bhutchings@...arflare.com>
Subject: RE: [RFC PATCH] netlink: Increase netlink dump skb message size

> -----Original Message-----
> From: netdev-owner@...r.kernel.org [mailto:netdev-owner@...r.kernel.org]
> On Behalf Of Eric Dumazet
> Sent: Wednesday, April 27, 2011 9:30 AM
> To: Steve Hodgson
> Cc: Rose, Gregory V; David Miller; netdev@...r.kernel.org;
> bhutchings@...arflare.com
> Subject: Re: [RFC PATCH] netlink: Increase netlink dump skb message size
> 
> Le mercredi 27 avril 2011 à 16:46 +0100, Steve Hodgson a écrit :
> > On 04/27/2011 04:24 PM, Eric Dumazet wrote:
> > > Le mardi 26 avril 2011 à 09:12 -0700, Rose, Gregory V a écrit :
> > >
> > >> I'm fine with however you folks want to approach this, just give me
> some direction.
> > >
> > > I would just try following patch :
> > >
> >
> > This allows the sfc driver to use 102 VFs, up from the current limit of
> > 45 VFs.
> >
> > It's unfortunate that this patch isn't sufficient to allow all 127 VFs
> > to be used, but whilst we wait for a new netlink api this is an
> > improvement worth having.
> >
> 
> netlink recvmsg() supports MSG_PEEK so user would get the needed size of
> its buffer before calling the real recvmsg()
> 
> big blobs could be attached as skb fragments (up to 64Kbytes), but do we
> really want this...
[Greg Rose] 

I'm looking into an approach in which we make the get info dump for VFs orthogonal to the set VF info, i.e. like this:

To set VF info we would follow the current convention:

# ip link set eth(x) vf (n) mac xx:xx:xx:xx:xx:xx
# ip link set eth(x) vf (n) vlan (nnnn)

To see VF info:

# ip link show eth(x) vf (n)

would show that VF's mac and vlan and could then be expanded in the future to display more information required for additional features that users are asking for.

The IFLA_VF_INFO dump would be moved out of the info dump for the physical function interface and would no longer be nested which would get rid of the need for huge amounts of buffer for info dumps on VFs.  The ip link show command for the PF would need to report the number of VFs currently allocated to the PF so that could fed into a script that loops to show each VFs info.

I think this approach would fix the problems we're looking at right now.

- Greg