Message-ID: <11832.1452627407@famine>
Date:	Tue, 12 Jan 2016 11:36:47 -0800
From:	Jay Vosburgh <jay.vosburgh@...onical.com>
To:	Lubomir Rintel <lkundrak@...sk>
cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	"David S. Miller" <davem@...emloft.net>,
	Veaceslav Falico <vfalico@...il.com>,
	Andy Gospodarek <gospo@...ulusnetworks.com>
Subject: Re: [PATCH 3/3] bonding: make device count build-time configurable

Lubomir Rintel <lkundrak@...sk> wrote:

>On Tue, 2016-01-12 at 08:34 -0800, Jay Vosburgh wrote:
>> Lubomir Rintel <lkundrak@...sk> wrote:
>> 
>> > The devices can be created at run-time for quite some time already
>> > and the
>> > load-time device creation collides with attempts to create the
>> > device of
>> > the same name:
>> > 
>> >  # rmmod bonding
>> >  # ip link add bond0 type bond
>> >  RTNETLINK answers: File exists
>> > 
>> > This is pretty much the same situation as was with the block loop
>> > devices
>> > which was solved by adding a build-time configuration that the
>> > distributions could use as they deem fit while keeping the default
>> > for
>> > compatibility.
>> 
>> 	I agree this is annoying, but I would expect distros to leave
>> this set to 1 (for backwards compatibility with scripts that
>> "modprobe
>> bonding" then assume bond0 exists).  This leaves the problem in place
>> for the vast majority of users.
>
>It's still an improvement to let the distributions decide if they're
>keeping "ip link add" broken or possibly affecting the scripts. Given
>the "modprobe bonding" didn't guarantee the bond0 bevice will be around
>at least since 2007 it think it's very reasonable for the distros to
>turn this off.

	This looks to me like one of those false "let the distros
decide" choices, as they'll likely all end up with the same settings, so
most users are going to see the same behaviors.

	If different distros set the various Kconfig options from this
patch series to a mish-mash of different settings, then it's not really
much of an improvement, either.  Anything cross-distro would still have
to work all ways, even if it keeps track of the kernel version.

>The network management tooling shipped with Fedora (both the legacy
>network service and NetworkManager) always did the right thing, be it
>writing to /sys/class/net/bonding_masters or adding the link via
>rtnetlink.

	And this is true for the Debian / Ubuntu scripts as well.

>Moreover, NetworkManager already specifically calls "modprobe bonding
>maxbonds=0" to avoid the creation of an extra "bond0" device (which
>coincidentally also breaks the naively written scripts if they are
>executed after NM creates a bond).

	The scripts I'm thinking of are not system provided, but
administrator or vendor created scripts that follow some of the now very
old instructions in the bonding.txt documentation, e.g.,

[... from bonding.txt ...]
        For example, if you wanted to make a simple bond of two e100
devices (presumed to be eth0 and eth1), and have it persist across
reboots, edit the appropriate file (/etc/init.d/boot.local or
/etc/rc.d/rc.local), and add the following:

modprobe bonding mode=balance-alb miimon=100
modprobe e100
ifconfig bond0 192.168.1.1 netmask 255.255.255.0 up
ip link set eth0 master bond0
ip link set eth1 master bond0

	They're probably (hopefully) old, but there are likely still
some lurking out there somewhere.  Whether these would ever be upgraded
to current kernels is a separate question; I've not seen scripts like
this in production use for a few years, but they were common at one
time.

>There's also a good prior art to this; as Daniel Borkmann pointed out
>in [1], Fedora ships a kernel with CONFIG_BLK_DEV_LOOP_MIN_COUNT=0
>happily for 4 releases already.
>
>[1] http://marc.info/?l=linux-netdev&m=145261483331891&w=2

	Ok, if it's been done before and apparently went just fine, then
the real intent here is to not auto-create bond0 (and the other devices
in the other patches of the series) in distro kernels, correct?  I.e.,
have the "count" values all set to zero, so that the module load doesn't
ever auto-create any of these devices.

	So, why not simply make the change (to not auto-create)
unilaterally, without the complexity of a set of Kconfig options that
are meant to always be overridden?

	I'll even help you here by shooting at my own argument: if the
old-style bonding scripts from the days of yore would already break if
brought forward from, say, RHEL 3 or 4 (about the last place I recall
seeing them) to something current, then is there any reason not to
simply make the bonding max_bonds=0 by default instead of 1?  Even then,
the administrator for a system could add "max_bonds=1" to a
/etc/modprobe.d/bonding.conf to restore the original behavior.

>> 	Is there a reasonable way to resolve this that would actually
>> fix things for regular distro kernel users?
>
>Depends on the definition of reasonable. Not being very familiar with
>the rtnetlink code, it would perhaps be possible to create some half-
>finished "bond0" device before doing a request_module(), so that the
>subsequently loaded module wouldn't take it over.
>
>It doesn't sound like a good idea to me as it would still cause an
>extra "bond0" device in case the user chooses a different name and the
>workarounds such as the one NetworkManager uses would still be
>necessary.

	Yah, any sort of hack in iproute is going to be ugly; I hadn't
really thought it through earlier.

	-J

---
	-Jay Vosburgh, jay.vosburgh@...onical.com

Powered by blists - more mailing lists