All of lore.kernel.org
 help / color / mirror / Atom feed
From: Veaceslav Falico <vfalico@redhat.com>
To: Vlad Yasevich <vyasevic@redhat.com>
Cc: Jay Vosburgh <jay.vosburgh@canonical.com>,
	netdev@vger.kernel.org, Andy Gospodarek <andy@greyhouse.net>,
	Ding Tianhong <dingtianhong@huawei.com>,
	Patric McHardy <kaber@trash.net>
Subject: Re: [PATCH v2 net] bonding: Fix stacked device detection in arp monitoring
Date: Wed, 7 May 2014 19:49:10 +0200	[thread overview]
Message-ID: <20140507174910.GT6295@redhat.com> (raw)
In-Reply-To: <536A6879.8070303@redhat.com>

On Wed, May 07, 2014 at 01:08:09PM -0400, Vlad Yasevich wrote:
...snip...
>Yes.  I verified that it works.  The reason is that we are traversing
>the all_adj_list.upper list which contains all of the upper devices at
>each level.  So, at vlan100 level, we will see vlan200 and all will be
>well.

Hrm, two scenarios, with the following config:

bond0 -> whatever1 -> vlan1 -> whatever2 -> vlan2 -> whatever3_IP

end == whatever3_IP

1) IIRC there are no guarantees on order of all_upper list, so, if
whatever3_IP dev is the first in the list - bond_check_patch() will return
true right away.

I might be wrong, though, it's 8PM and my brain farts when trying to look
at that code.

That's fixable (from first sight) by introducing a variable upper_found:

+       netdev_for_each_all_upper_dev_rcu(start, upper, iter) {
...
+               if (upper == end)
+                       upper_found = true;
...
+       }
+       return upper_found;

This way it will first try to go through all nested vlans and, if none
found, will return true. Basically, "return upper_found (=true)" has the
meaning that upper was found and there are no vlans in between.

The "wrong" order might be achieved by creating a bridge for whatever2,
creating and linking vlan2 and whatever3_IP, and only *after* that adding
vlan1 as a port to bridge whatever2.

2) (with the fix from #1 applied)

bond_check_path start==bond0 idx=0
finds vlan1, tag[0] set, recursion start==vlan1 idx=1
bond_check_path start==vlan1 idx=1
finds vlan2, tag[1] set, recursion start==vlan2 idx=2
returns right away with false as idx >= 2.

That's wrong as there might be vlan3 on top of whatever2, and tag[1] might
be set to it, whilst vlan3 has nothing to do with whatever3_IP.

The fix here would be to halt on idx > 2, or, rather, to NOT use
recursion/vlan checks if idx == 2, thus leaving us with only upper_found
logic.

So, the end patch (not compiled, not tested...) would look something like
(only the bond_check_path() is changed and copied here, everything else
remains the same):

+       bool upper_found = false;
+
+       netdev_for_each_all_upper_dev_rcu(start, upper, iter) {
+               if (upper == end)
+                       upper_found = true;
+
+               if (idx < 2 && is_vlan_dev(upper) &&
+                   bond_check_path(upper, end, tag, idx+1)) {
+                       tag[idx].vlan_proto = vlan_dev_vlan_proto(upper);
+                       tag[idx].vlan_id = vlan_dev_vlan_id(upper);
+                       return true;
+               }
+       }
+       return upper_found;

This way we'll collect the maximum ammount of stacked vlans on our trip
from bond0 to whatever3_IP (the limit is 2, however it might be removed
afterwards if needed, will still work with long enough tag[]).

Hope that makes at least some sense.

>
>-vlad
...snip...

  reply	other threads:[~2014-05-07 17:49 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-07 13:47 [PATCH v2 net] bonding: Fix stacked device detection in arp monitoring Vlad Yasevich
2014-05-07 16:43 ` Jay Vosburgh
2014-05-07 17:08   ` Vlad Yasevich
2014-05-07 17:49     ` Veaceslav Falico [this message]
2014-05-07 18:11       ` Veaceslav Falico
2014-05-07 18:47         ` Vlad Yasevich
2014-05-07 18:59           ` Veaceslav Falico
2014-05-07 19:40             ` Jay Vosburgh
2014-05-07 20:10             ` Veaceslav Falico
2014-05-08  4:25               ` Ding Tianhong

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=20140507174910.GT6295@redhat.com \
    --to=vfalico@redhat.com \
    --cc=andy@greyhouse.net \
    --cc=dingtianhong@huawei.com \
    --cc=jay.vosburgh@canonical.com \
    --cc=kaber@trash.net \
    --cc=netdev@vger.kernel.org \
    --cc=vyasevic@redhat.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.