From: "Nicolas de Pesloüan" <nicolas.2p.debian@gmail.com>
To: Jay Vosburgh <fubar@us.ibm.com>
Cc: "Michał Górny" <mgorny@gentoo.org>,
netdev@vger.kernel.org, roy@marples.name,
"Andy Gospodarek" <andy@greyhouse.net>
Subject: Re: The bonding driver should notify userspace of MAC address change
Date: Fri, 15 Apr 2011 21:22:04 +0200 [thread overview]
Message-ID: <4DA89ADC.7040808@gmail.com> (raw)
In-Reply-To: <10227.1302893590@death>
Le 15/04/2011 20:53, Jay Vosburgh a écrit :
> Nicolas de Pesloüan <nicolas.2p.debian@gmail.com> wrote:
>
>> Le 15/04/2011 18:44, Michał Górny a écrit :
>>> Hello,
>>>
>>> I'd like to file a feature request for the bonding driver. Currently,
>>> there is no way for userspace to know whether the driver actually gets
>>> a MAC address. This results in the fact that dhcpcd sends MAC-less DHCP
>>> packets through bonding device if it is started before bond gets any
>>> slaves.
>>
>> A similar subject, involving bridge instead of bonding, was discussed a
>> few weeks ago in this thread:
>> http://marc.info/?l=linux-netdev&m=129939017116310&w=2
>>
>> In particular, I suggested to apply Stephen's suggestion not only to bridge but also to bonding.
>>
>> (http://marc.info/?l=linux-netdev&m=129948385024680&w=2)
>>
>> A bonding device should not report link up to userspace until at least one slave is present and up.
>>
>> And possibly, a bonding device should report link down if all slaves are down or all slave were removed.
>>
>> Jay, Andy, does this sounds sensible to you?
>
> I was just reading their bug and doing an experiment; I don't
> see that bonding reports carrier up until there's at least one slave
> (even if it's configured up), e.g.,
>
> # modprobe bonding
> # ifconfig bond0 up
> # cat /sys/class/net/bond0/carrier
> 0
> # echo +eth5> /sys/class/net/bond0/bonding/slaves
> # cat /sys/class/net/bond0/carrier
> 1
>
> If there's a slave, there's a MAC assigned, since bond_enslave
> sets the master's MAC before it calls bond_set_carrier.
>
> In bond_create, as soon as register_netdevice returns, we call
> netif_carrier_off, and it stays off until bond_enslave runs
> successfully.
Agreed.
> Is there some race window there between the register and the
> netif_carrier_off?
It might be that dhcpd does not wait for link to be up before starting to send DHCP requests.
Nicolas.
next prev parent reply other threads:[~2011-04-15 19:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-04-15 16:44 The bonding driver should notify userspace of MAC address change Michał Górny
2011-04-15 18:40 ` Nicolas de Pesloüan
2011-04-15 18:53 ` Jay Vosburgh
2011-04-15 19:10 ` [RFC net-next] bonding: notify when bonding device address changes Stephen Hemminger
2011-04-15 19:28 ` Jay Vosburgh
2011-04-16 16:18 ` Stephen Hemminger
2011-04-15 19:12 ` The bonding driver should notify userspace of MAC address change Phil Oester
2011-04-15 19:22 ` Jay Vosburgh
2011-04-15 19:22 ` Nicolas de Pesloüan [this message]
2011-04-15 21:45 ` Jay Vosburgh
2011-04-16 9:07 ` Nicolas de Pesloüan
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=4DA89ADC.7040808@gmail.com \
--to=nicolas.2p.debian@gmail.com \
--cc=andy@greyhouse.net \
--cc=fubar@us.ibm.com \
--cc=mgorny@gentoo.org \
--cc=netdev@vger.kernel.org \
--cc=roy@marples.name \
/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).