netdev - Re: RFC: rtnetlink problems with Cisco enic and VFs

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]

Message-Id: <20140423111203.3e8cf3a9a12acb1d95b3635a@redhat.com>
Date:	Wed, 23 Apr 2014 11:12:03 +1000
From:	David Gibson <dgibson@...hat.com>
To:	Greg Rose <gregory.v.rose@...el.com>
Cc:	David Miller <davem@...emloft.net>, <ben@...adent.org.uk>,
	<netdev@...r.kernel.org>, <benve@...co.com>, <ssujith@...co.com>,
	<govindarajulu90@...il.com>, <neepatel@...co.com>,
	<nistrive@...co.com>
Subject: Re: RFC: rtnetlink problems with Cisco enic and VFs

On Tue, 22 Apr 2014 17:04:38 -0700
Greg Rose <gregory.v.rose@...el.com> wrote:

> On Wed, 23 Apr 2014 09:26:06 +1000
> David Gibson <dgibson@...hat.com> wrote:
> 
> > On Tue, 22 Apr 2014 14:12:00 -0400 (EDT)
> > David Miller <davem@...emloft.net> wrote:
> > 
> > > From: Ben Hutchings <ben@...adent.org.uk>
> > > Date: Tue, 22 Apr 2014 19:03:19 +0100
> > > 
> > > > On Tue, 2014-04-22 at 14:14 +1000, David Gibson wrote:
> > > >> I believe I've found a problem with netlink handling which can be
> > > >> triggered on Cisco enic devices with a large number (30-40) of
> > > >> virtual functions.  I believe this is the cause of a real
> > > >> customer problem we've seen.
> > > >> 
> > > >>  * When requesting a list of interfaces with RTM_GETLINK, enic
> > > >> devices (and currently, _only_ enic devices) report IFLA_VF_PORTS
> > > >>    information 
> > > >> 
> > > >>  * IFLA_VF_PORTS information has at least 90 bytes ber virtual
> > > >> function
> > > >> 
> > > >>  * Unlike IFLA_VFINFO_LIST, the ports information is always
> > > >> reported, regardless of the setting of the IFLA_EXT_MASK
> > > >> parameter
> > > > [...]
> > > > 
> > > > So I think you should make reporting of IFLA_VF_PORTS dependent
> > > > on the same flag as IFLA_VFINFO_LIST.
> > > 
> > > I think that's what we'll have to do.
> > 
> > Ok, makes logical sense.
> > 
> > But does anyone know what tools make use of the IFLA_VF_PORTS
> > information?  Do they set the IFLA_EXT_MASK already?
> > 
> 
> So far as I know only the IP route tool 'ip link' sets that.  In fact,
> that's the reason I had to add it some number of years and months ago
> was because there were tools that didn't expect to get all the
> additional VF info and those tools were getting borked by all the
> additional goo sent up for VFs.
> 
> Beyond that who knows what anyone's been up to with other tools in
> other places?

And therein lies the problem.  I don't even know what the IFLA_VF_PORTS
info is for, but presumably something uses it.  If they stop receiving
it, they can be expected to break horribly.

-- 
David Gibson <dgibson@...hat.com>

Content of type "application/pgp-signature" skipped