linux-kernel - Re: [patch net-next v2 01/15] net: introduce upper device lists

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: <1344983624.2690.77.camel@bwh-desktop.uk.solarflarecom.com>
Date:	Tue, 14 Aug 2012 23:33:44 +0100
From:	Ben Hutchings <bhutchings@...arflare.com>
To:	Jiri Pirko <jiri@...nulli.us>
CC:	<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 01/15] net: introduce upper device lists

On Tue, 2012-08-14 at 17:05 +0200, Jiri Pirko wrote:
> This lists are supposed to serve for storing pointers to all upper devices.
> Eventually it will replace dev->master pointer which is used for
> bonding, bridge, team but it cannot be used for vlan, macvlan where
> there might be multiple upper present. In case the upper link is
> replacement for dev->master, it is marked with "master" flag.

Something I found interesting is that the dev->master pointer and now
netdev_master_upper_dev_get{,_rcu}() are hardly used by the stackled
drivers that set the master.  They also have to set an rx_handler on the
lower device (which is itself mutually exclusive) which gets its own
context pointer (rx_handler_data).

Instead, the master pointer is mostly used by device drivers to find out
about a bridge or bonding device above *their* devices.  And that seems
to work only for those specific device drivers, not e.g. openvswitch or
team.  I wonder if we could find a better way to encapsulate the things
they want do do, in a later step (not holding up this change!).

[...]
> +static int __netdev_upper_dev_link(struct net_device *dev,
> +                                  struct net_device *upper_dev, bool master)
> +{
> +       struct netdev_upper *upper;
> +
> +       ASSERT_RTNL();
> +
> +       if (dev == upper_dev)
> +               return -EBUSY;
> +       /*
> +        * To prevent loops, check if dev is not upper device to upper_dev.
> +        */
> +       if (__netdev_has_upper_dev(upper_dev, dev, true))
> +               return -EBUSY;
[...]

I think we will also need to limit the depth of the device stack so we
don't run out of stack space here.  __netif_receive() implements a kind
of tail recursion whenever a packet is passed up, but
__netdev_has_upper_dev() can't avoid doing real recursion (without the
addition of a flag to net_device so it can mark its progress).

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 linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/