All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jay Vosburgh <jay.vosburgh@canonical.com>
To: Karl Heiss <kheiss@gmail.com>
Cc: Veaceslav Falico <vfalico@gmail.com>,
	Andy Gospodarek <gospo@cumulusnetworks.com>,
	netdev@vger.kernel.org
Subject: Re: [PATCH net] bonding: Prevent IPv6 link local address on enslaved devices
Date: Fri, 08 Jan 2016 12:51:17 -0800	[thread overview]
Message-ID: <5842.1452286277@famine> (raw)
In-Reply-To: <CAGugRbXT3jXw1-42Nz6ci-PS7z+HUj_fG2zcwK45dM6pb+RnqQ@mail.gmail.com>

Karl Heiss <kheiss@gmail.com> wrote:

>On Fri, Jan 8, 2016 at 2:56 PM, Jay Vosburgh <jay.vosburgh@canonical.com> wrote:
>> Karl Heiss <kheiss@gmail.com> wrote:
[...]
>>>@@ -1216,7 +1215,6 @@ static void bond_upper_dev_unlink(struct net_device *bond_dev,
>>>                                 struct net_device *slave_dev)
>>> {
>>>       netdev_upper_dev_unlink(slave_dev, bond_dev);
>>>-      slave_dev->flags &= ~IFF_SLAVE;
>>>       rtmsg_ifinfo(RTM_NEWLINK, slave_dev, IFF_SLAVE, GFP_KERNEL);
>>> }
>>
>>         Will this change cause issues for user space monitoring of the
>> RTM_NEWLINKs, as now the message will have IFF_SLAVE in the flags for
>> both the "link" and "unlink" cases?  How would link be distinguished
>> from unlink?
>>
>>         Since the unlink happens only in __bond_release_one or in the
>> case of a failure within bond_enslave, does clearing the flag in
>> bond_upper_dev_unlink cause any actual issues?
>>
>>         -J
>>
>
>Oops.  You are correct that the RTM_NEWLINK would appear to be identical to
>the link case.  I had originally done this to prevent any NETDEV_CHANGE events
>from causing the link local address and subsequent neighbor advertisements just
>as the device is unlinked.  However, the bond_upper_dev_unlink() changes were a
>result of speculation, not actual observation.
>
>If we feel that we are safe from any NETDEV_CHANGE events and/or the
>consequences during unlink, I am fine with leaving the bond_upper_dev_unlink()
>code as-is.

	I looked briefly, and I don't see a source of NETDEV_CHANGE
notifiers between the bond_upper_dev_unlink and dev_close calls in
__bond_release_one.  Note that dev_set_promiscuity / allmulti do end up
in __dev_notify_flags, but it excludes NETDEV_CHANGE for PROMISC and
ALLMULTI, so I think that's not an issue.

	-J

---
	-Jay Vosburgh, jay.vosburgh@canonical.com

      reply	other threads:[~2016-01-08 20:51 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-08 19:33 [PATCH net] bonding: Prevent IPv6 link local address on enslaved devices Karl Heiss
2016-01-08 19:56 ` Jay Vosburgh
2016-01-08 20:34   ` Karl Heiss
2016-01-08 20:51     ` Jay Vosburgh [this message]

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=5842.1452286277@famine \
    --to=jay.vosburgh@canonical.com \
    --cc=gospo@cumulusnetworks.com \
    --cc=kheiss@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=vfalico@gmail.com \
    /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.