netdev - Re: [PATCH net-next 00/25] bonding: introduce new option API

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: <E9519D4C-39CA-47D8-92E9-5CD6909571D8@cumulusnetworks.com>
Date:	Tue, 21 Jan 2014 13:51:02 -0800
From:	Scott Feldman <sfeldma@...ulusnetworks.com>
To:	Dan Williams <dcbw@...hat.com>
Cc:	Nikolay Aleksandrov <nikolay@...hat.com>,
	Netdev <netdev@...r.kernel.org>,
	Andy Gospodarek <andy@...yhouse.net>,
	Jay Vosburgh <fubar@...ibm.com>,
	Veaceslav Falico <vfalico@...hat.com>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH net-next 00/25] bonding: introduce new option API


On Jan 21, 2014, at 7:59 AM, Dan Williams <dcbw@...hat.com> wrote:

> On Tue, 2014-01-21 at 15:54 +0100, Nikolay Aleksandrov wrote:
>> Hi,
>> This patchset's goal is to introduce a new option API which should be used
>> to properly describe the bonding options with their mode dependcies and
>> requirements. With this patchset applied we get centralized option
>> manipulation, automatic RTNL acquire per option setting, automatic option
>> range checking, mode dependcy checking and other various flags which are
>> described in detail in patch 01's commit message and comments.
>> Also the parameter passing is changed to use a specialized structure which
>> is initialized to a value depending on the needs.
> 
> Currently userspace has to encode a lot of the same logic the kernel has
> for option validation, for example when creating a user interface for
> this stuff, you have to know that miimon and arp are incompatible, and
> that certain options are only relevant with certain bond modes, and it's
> a mess.  And this also sometimes changes when new kernel options or
> capabilities are added.

Note that if using the new netlink support for bonding via an updated ip link command, incompatible options will be caught and the command will fail.  For example, if you try to create a new bond and set both miimon and arp, the bond create will fail (and err msg logged).  Once the bond is created, again trying to set incompatible options with one command will fail in the same way.  If options are set one at a time on existing bond, then last set option takes precedence and may override earlier settings.

None of this is true if using sysfs.  So user-space tools should move to ip link (or netlink directly) rather than using sysfs for bond config.

> 
> So, is there any good way to describe the valid value ranges or
> capabilities for userspace?  One idea is to send a package of bond
> options to the kernel and see if they validate before actually applying
> them, though this only works when actually configuring the interface.
> An additional idea would be to somehow describe the available options
> (eg, value ranges for numeric values, list-of-strings for bond modes,
> etc) that the kernel supports before any bonds are even created (thus
> probably through netlink, not sysfs).
> 
> Thoughts?

--
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