All of lore.kernel.org
 help / color / mirror / Atom feed
From: Veaceslav Falico <vfalico@redhat.com>
To: Vlad Yasevich <vyasevic@redhat.com>
Cc: Stefan Priebe <s.priebe@profihost.ag>,
	Vlad Yasevich <vyasevich@gmail.com>,
	Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10
Date: Thu, 14 Nov 2013 12:54:51 +0100	[thread overview]
Message-ID: <20131114115451.GT19702@redhat.com> (raw)
In-Reply-To: <52843EEA.3020905@redhat.com>

On Wed, Nov 13, 2013 at 10:09:30PM -0500, Vlad Yasevich wrote:
>Can you try out attached patch please.  I ran it in my environment and
>always get promisc link when attaching devices to the bridge.

It's interesting, actually, why do we need to check for IFF_UP at all when
changing flags.

The addition of IFF_UP goes up to:

commit b6c40d68ff6498b7f63ddf97cf0aa818d748dee7
Author: Patrick McHardy <kaber@trash.net>
Date:   Tue Oct 7 15:26:48 2008 -0700

     net: only invoke dev->change_rx_flags when device is UP

     Jesper Dangaard Brouer <hawk@comx.dk> reported a bug when setting a VLAN
     device down that is in promiscous mode:

     When the VLAN device is set down, the promiscous count on the real
     device is decremented by one by vlan_dev_stop(). When removing the
     promiscous flag from the VLAN device afterwards, the promiscous
     count on the real device is decremented a second time by the
     vlan_change_rx_flags() callback.

... snip ...

However, I'm not sure that this is still needed, cause:

commit deede2fabe24e00bd7e246eb81cd5767dc6fcfc7
Author: Matthijs Kooijman <matthijs@stdin.nl>
Date:   Mon Oct 31 04:53:13 2011 +0000

     vlan: Don't propagate flag changes on down interfaces.

     When (de)configuring a vlan interface, the IFF_ALLMULTI ans IFF_PROMISC
     flags are cleared or set on the underlying interface. So, if these flags
     are changed on a vlan interface that is not up, the flags underlying
     interface might be set or cleared twice.

     Only propagating flag changes when a device is up makes sure this does
     not happen. It also makes sure that an underlying device is not set to
     promiscuous or allmulti mode for a vlan device that is down.

... snip ...

which fixed completely the initial issue with vlans.

Maybe we should just remove the IFF_UP check in dev_change_rx_flags(), and
let the drivers using it handle its own logic, as vlan does?

Something like this:

diff --git a/net/core/dev.c b/net/core/dev.c
index 8ffc52e..9615cd7 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -4995,7 +4995,7 @@ static void dev_change_rx_flags(struct net_device *dev, int flags)
  {
  	const struct net_device_ops *ops = dev->netdev_ops;
  
-	if ((dev->flags & IFF_UP) && ops->ndo_change_rx_flags)
+	if (ops->ndo_change_rx_flags)
  		ops->ndo_change_rx_flags(dev, flags);
  }
  

>
>Thanks
>-vlad

  parent reply	other threads:[~2013-11-14 11:57 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-13 13:58 how to mix bridges and bonding inc. vlans correctly on Kernel > 3.10 Stefan Priebe - Profihost AG
2013-11-13 14:12 ` Veaceslav Falico
2013-11-13 14:20   ` Stefan Priebe - Profihost AG
2013-11-13 14:34     ` Veaceslav Falico
2013-11-13 14:43       ` Stefan Priebe - Profihost AG
2013-11-13 15:05     ` Vlad Yasevich
2013-11-13 15:17       ` Stefan Priebe - Profihost AG
2013-11-13 16:21         ` Veaceslav Falico
2013-11-13 16:43           ` Stefan Priebe - Profihost AG
2013-11-13 17:21           ` Vlad Yasevich
2013-11-13 20:09             ` Stefan Priebe
2013-11-14  3:09               ` Vlad Yasevich
2013-11-14  7:47                 ` Stefan Priebe - Profihost AG
2013-11-14 12:29                   ` Veaceslav Falico
2013-11-14 21:13                     ` Vlad Yasevich
2013-11-16 21:02                       ` Stefan Priebe
2013-11-17  3:41                         ` Vladislav Yasevich
2013-11-18  7:37                           ` Stefan Priebe - Profihost AG
2013-11-14 11:54                 ` Veaceslav Falico [this message]
2013-11-14 14:27                   ` Vlad Yasevich
2013-11-14 14:29                     ` Stefan Priebe - Profihost AG
2013-11-14 14:41                       ` Vlad Yasevich
2013-11-16 21:00                         ` Stefan Priebe
2013-11-13 16:44         ` Vlad Yasevich
2013-11-13 17:22           ` Stefan Priebe - Profihost AG
2013-11-13 17:37             ` Vlad Yasevich
2013-11-13 17:46               ` Stefan Priebe - Profihost AG
2013-11-13 17:49                 ` Vlad Yasevich

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=20131114115451.GT19702@redhat.com \
    --to=vfalico@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=s.priebe@profihost.ag \
    --cc=vyasevic@redhat.com \
    --cc=vyasevich@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.