netdev - Re: [PATCH 0/6] Bonding simplifications and netns support

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:	Fri, 30 Oct 2009 03:39:53 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	David Miller <davem@...emloft.net>
Cc:	netdev@...r.kernel.org, fubar@...ibm.com
Subject: Re: [PATCH 0/6] Bonding simplifications and netns support

ebiederm@...ssion.com (Eric W. Biederman) writes:

> David Miller <davem@...emloft.net> writes:
>
>> From: ebiederm@...ssion.com (Eric W. Biederman)
>> Date: Thu, 29 Oct 2009 17:16:54 -0700
>>
>>> I recently had it pointed out to me that the bonding driver does not
>>> work in a network namespace.  So I have simplified the bonding driver
>>> a bit, added support for ip link add and ip link del, and finally made
>>> the bonding driver work in multiple network namespaces.
>>> 
>>> The most note worthy change in the patchset is the addition of support
>>> in the networking core for registering a sysfs group for a device.
>>> 
>>> Using this in the bonding driver simplifies the code and removes a
>>> userspace race between actions triggered by the netlink event and the
>>> bonding sysfs attributes appearing.
>>
>> I have no objections to these patches, but I'd like the bonding
>> folks to have a chance to look at it before I apply to net-next-2.6
>
> Sure.
>
>> One question though, are you sure this clever extra slot scheme
>> in patch #1 works for, f.e., a bond of wireless devices?  It seems
>> like it would work out, but I wanted to ask to make sure you
>> considered that case.
>
> I have not explicitly tested wireless devices.  But I did make certain
> we have enough slots in the array.  I did write the code so that a
> device driver can use at most one slot (the next slot gets
> unconditionally stomped).  Other that it is just shifting of where
> sysfs_create_group and sysfs_remove_group are called.  So I would
> be totally stunned if bonded wireless devices started failing from
> this change.

Bah.  The argument is better than that.  The bond_group that I am
messing with only applies to the virtual bonding devices.  The virtual
bond device is never a wireless device.  So we will never see in
practice all three groups on the same network device.

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