netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: David Miller <davem@davemloft.net>
Cc: netdev@vger.kernel.org, fubar@us.ibm.com
Subject: Re: [PATCH 0/6] Bonding simplifications and netns support
Date: Fri, 30 Oct 2009 03:39:53 -0700	[thread overview]
Message-ID: <m1d445qi6e.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <m11vkltj4z.fsf@fess.ebiederm.org> (Eric W. Biederman's message of "Fri\, 30 Oct 2009 00\:50\:52 -0700")

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

> David Miller <davem@davemloft.net> writes:
>
>> From: ebiederm@xmission.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

  reply	other threads:[~2009-10-30 10:39 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-10-30  0:16 [PATCH 0/6] Bonding simplifications and netns support Eric W. Biederman
2009-10-30  0:18 ` [PATCH 1/6] net: Allow devices to specify a device specific sysfs group Eric W. Biederman
2009-10-30  0:18 ` [PATCH 2/6] bond: Simply bond sysfs group creation Eric W. Biederman
2009-10-30  0:18 ` [PATCH 3/6] bond: Simplify bond_create Eric W. Biederman
2009-10-30  0:18 ` [PATCH 4/6] bond: Simplify bond device destruction Eric W. Biederman
2009-10-30  0:18 ` [PATCH 5/6] bond: Implement a basic set of rtnl link ops Eric W. Biederman
2009-10-30  8:06   ` Patrick McHardy
2009-10-30  8:29   ` Patrick McHardy
2009-10-30  9:23     ` Eric W. Biederman
2009-10-30  9:33       ` Patrick McHardy
2009-10-30  9:58         ` [PATCH 7/6] bond: Get the rtnl_link_ops support correct Eric W. Biederman
2009-10-30 10:00         ` [PATCH 5/6] bond: Implement a basic set of rtnl link ops Eric W. Biederman
2009-10-30 10:08           ` Patrick McHardy
2009-10-30  0:18 ` [PATCH 6/6] bond: Add support for multiple network namespaces Eric W. Biederman
2009-10-30  6:25 ` [PATCH 0/6] Bonding simplifications and netns support David Miller
2009-10-30  6:38   ` Eric Dumazet
2009-10-30  6:40     ` David Miller
2009-10-30  7:50   ` Eric W. Biederman
2009-10-30 10:39     ` Eric W. Biederman [this message]
2009-10-30 19:41 ` David Miller
2009-10-30 21:12   ` Jay Vosburgh
2009-10-30 22:57     ` Eric W. Biederman
2009-10-31  0:10       ` Jay Vosburgh
2009-10-31  1:06         ` Eric W. Biederman
2009-10-31  1:45           ` Jay Vosburgh
2009-10-31  0:27     ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1d445qi6e.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=davem@davemloft.net \
    --cc=fubar@us.ibm.com \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).