From: Mike Manning <mmanning@brocade.com>
To: David Miller <davem@davemloft.net>
Cc: <netdev@vger.kernel.org>
Subject: Re: [PATCH net] vlan: Propagate MAC address changes properly
Date: Tue, 3 May 2016 16:18:42 +0100 [thread overview]
Message-ID: <5728C152.7090007@brocade.com> (raw)
In-Reply-To: <20160503.001651.132843090236435270.davem@davemloft.net>
On 05/03/2016 05:16 AM, David Miller wrote:
> From: Mike Manning <mmanning@brocade.com>
> Date: Sat, 30 Apr 2016 11:32:37 +0100
>
>> The MAC address of the physical interface is only copied to the VLAN
>> when it is first created, resulting in an inconsistency after MAC
>> address changes of only newly created VLANs having an up-to-date MAC.
>>
>> Continuing to inherit the MAC address unless explicitly changed for
>> the VLAN allows IPv6 EUI64 addresses for the VLAN to reflect the change
>> and thus for DAD to behave as expected for the given MAC.
>>
>> Signed-off-by: Mike Manning <mmanning@brocade.com>
>
> What is this code really trying to achieve?
>
> Is it "Propagate real device MAC changes to undelying vlan device,
> but not if the user set the vlan MAC explicitly."?
Right, I will update the subject header to make this clearer
>
> If so, implement that instead of all of these confusing tests.
>
> If the vlan device's set_mac_address operation is ever called,
> set a boolean value in the vlan device private to true and test
> it here.
>
Given that this information is implicit in real_dev_addr, I am reluctant
to add another member to the vlan_dev_priv data structure, especially given
that there may be a large number of VLANs. Instead I have added a variable
real_addr_in_use in vlan_sync_address() to make this clearer.
next prev parent reply other threads:[~2016-05-03 15:18 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5723D930.6040004@brocade.com>
2016-04-30 10:32 ` [PATCH net] vlan: Propagate MAC address changes properly Mike Manning
2016-05-03 4:16 ` David Miller
2016-05-03 15:18 ` Mike Manning [this message]
2016-05-03 16:34 ` David Miller
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=5728C152.7090007@brocade.com \
--to=mmanning@brocade.com \
--cc=davem@davemloft.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.