netdev - Re: [patch net-next v2 00/15] net: introduce upper device lists and remove dev->master

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:	Tue, 14 Aug 2012 21:32:53 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Andy Gospodarek <gospo@...hat.com>
CC:	Jiri Pirko <jiri@...nulli.us>, <netdev@...r.kernel.org>,
	<davem@...emloft.net>, <edumazet@...gle.com>,
	<faisal.latif@...el.com>, <roland@...nel.org>,
	<sean.hefty@...el.com>, <hal.rosenstock@...il.com>,
	<fubar@...ibm.com>, <andy@...yhouse.net>, <divy@...lsio.com>,
	<jitendra.kalsaria@...gic.com>, <sony.chacko@...gic.com>,
	<linux-driver@...gic.com>, <kaber@...sh.net>,
	<ursula.braun@...ibm.com>, <blaschka@...ux.vnet.ibm.com>,
	<linux390@...ibm.com>, <shemminger@...tta.com>,
	<therbert@...gle.com>, <xiyou.wangcong@...il.com>,
	<joe@...ches.com>, <gregory.v.rose@...el.com>,
	<john.r.fastabend@...el.com>, <linux-rdma@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-s390@...r.kernel.org>,
	<bridge@...ts.linux-foundation.org>, <fbl@...hat.com>
Subject: Re: [patch net-next v2 00/15] net: introduce upper device lists and
 remove dev->master

On Tue, 2012-08-14 at 16:19 -0400, Andy Gospodarek wrote:
> On Tue, Aug 14, 2012 at 05:05:33PM +0200, Jiri Pirko wrote:
> > Hi all.
> > 
> > Recent discussion around
> > "[net-next] bonding: don't allow the master to become its slave"
> > forced me to think about upper<->lower device connections.
> > 
> > This patchset adds a possibility to record upper device linkage.
> > All upper<->lower devices are converted to use this mechanism right after.
> > That leads to dev->master removal because this info becomes redundant since
> > "unique links" have the same value.
> > 
> > After all changes, there is no longer possible to do:
> > "bond->someotherdevice->samebond"
> > 
> > Also I think that drivers like cxgb3, qlcnic, qeth would benefit by this
> > in future by being able to get more appropriate info about l3 addresses.
> > 
> > v1->v2:
> > - s/unique/master/ better naming + stays closer to the history
> > - fixed vlan err goto
> > - original patch 15 (WARN_ON change) is squashed into the first patch
> > - fixed netdev_unique_upper_dev_get_rcu() case of upper==NULL
> I just started to review v1 when v2 came out, but luckily the changes
> were not too significant that I need to start all over.
> 
> The first note is that I didn't like the use of the term 'upper' -- it
> seems like 'stacked' might be a better alternative as these are stacked
> devices.

When linking any two devices in a stack, one will be upper and the other
lower.  The lower device might itself be stacked on top of a further
device, so 'stacked' is not a useful distinguishing adjective in
variable names.  It might be a useful term in the commit messages and
kernel-doc, though.

> One thing to note is that I don't see any clear changelog that states
> the current goals for this.  You have stated in several places that it
> will no longer be possible to create bonds of bonds, but there are
> probably a few more things it might be wise to intentionally outlaw.
>
> What about teams of teams?  Or teams of bonds?  Or bonds of teams?
> Bonds of vlans?
[...]

It doesn't disallow bonds of bonds (unless I'm missing something).  It
disallows loops that involve any or all of those types of stacked
devices.

Ben.

-- 
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html