From: Stephen Hemminger <stephen@networkplumber.org>
To: netdev@vger.kernel.org
Subject: Fw: [Bug 198297] New: Unable to add ethX to bridge if ethX.<VLAN_ID> is already present in this bridge
Date: Thu, 28 Dec 2017 09:08:14 -0800 [thread overview]
Message-ID: <20171228090814.2e425bb3@xeon-e3> (raw)
I don't think this is ever going to work as expected.
Begin forwarded message:
Date: Thu, 28 Dec 2017 08:38:37 +0000
From: bugzilla-daemon@bugzilla.kernel.org
To: stephen@networkplumber.org
Subject: [Bug 198297] New: Unable to add ethX to bridge if ethX.<VLAN_ID> is already present in this bridge
https://bugzilla.kernel.org/show_bug.cgi?id=198297
Bug ID: 198297
Summary: Unable to add ethX to bridge if ethX.<VLAN_ID> is
already present in this bridge
Product: Networking
Version: 2.5
Kernel Version: 4.14.2
Hardware: ARM
OS: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: Other
Assignee: stephen@networkplumber.org
Reporter: alexander_cheremshinsky@yahoo.com
Regression: No
Kernel fails adding ethX to bridge if ethX.<VLAN_ID> is already present in this
bridge.
Steps to reproduce:
# vconfig add eth2 10
# brctl addbr br
# brctl addif br eth2.10
# brctl show
bridge name bridge id STP enabled interfaces
br 8000.0024a407481a no eth2.10
# brctl addif br eth2
can't add eth2 to bridge br: File exists
# brctl show
bridge name bridge id STP enabled interfaces
br 8000.0024a407481a no eth2.10
But it is ok if ethX is added before ethX.<VLAN_ID>
Steps to reproduce:
# brctl delif br eth2.10
# brctl addif br eth2
# brctl addif br eth2.10
# brctl show
bridge name bridge id STP enabled interfaces
br 8000.0024a407481a no eth2
eth2.10
So the result is depending on order of interface addition, that does not looks
logical as for me. This works good at least in kernel 3.10.70.
From my investigation it fails in function __netdev_upper_dev_link
(net/core/dev.c) on lines:
if (netdev_has_upper_dev(dev, upper_dev))
return -EEXIST;
I checked source code of kernel 4.14.8 but it looks the same and I think it
also has this issue.
I'm not so good with linux kernel to fix this by myself so it would be very
nice to get a patch with fix for this issue or explanation why such behavior is
correct.
Thanks in advance,
Alex.
--
You are receiving this mail because:
You are the assignee for the bug.
reply other threads:[~2017-12-28 17:08 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20171228090814.2e425bb3@xeon-e3 \
--to=stephen@networkplumber.org \
--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 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).