Bug 1086897 - bridging_opts fail to apply due to race with creating the bridge
Summary: bridging_opts fail to apply due to race with creating the bridge
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: initscripts
Version: 6.5
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Lukáš Nykrýn
QA Contact: Jan Ščotka
URL:
Whiteboard:
Depends On:
Blocks: 1129624 1138719
TreeView+ depends on / blocked
 
Reported: 2014-04-11 19:09 UTC by Antoni Segura Puimedon
Modified: 2017-02-07 13:45 UTC (History)
10 users (show)

Fixed In Version: initscripts-9.03.41-1.el6
Doc Type: Bug Fix
Doc Text:
In BRIDGING_OPTS options "multicast_router" and "hash_max" can be applied after the bridge is up. So lets apply them after the bridge is up.
Clone Of:
: 1129624 1138719 (view as bug list)
Environment:
Last Closed: 2014-10-14 06:28:20 UTC
Target Upstream Version:


Attachments (Terms of Use)
Completely untested patch which could solve this from initscripts side. (848 bytes, patch)
2014-04-14 17:36 UTC, Lukáš Nykrýn
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1448 0 normal SHIPPED_LIVE initscripts bug fix and enhancement update 2014-10-14 01:05:44 UTC

Description Antoni Segura Puimedon 2014-04-11 19:09:32 UTC
Description of problem:
When a bridge does not exist and the ifcfg file contains bridging_opts,
ifup-eth first creates the bridge doing:
    brctl addbr <bridge_name>
Just after that it iterates through the bridging_opts echoing the values to
    /sys/class/net/<bridge_name>/bridge/<key_name>

The problem is that when echoing the value to the bridge sysfs entries, those
entries will not yet exist, as some, like multicast_router are created after
the link is put up.



Version-Release number of selected component (if applicable):
initscripts-9.03.40-2.el6.x86_64

How reproducible: 100%


Steps to Reproduce:
1. Create a bridge named 'tar' with the following ifcfg-tar:
    DEVICE=tar
    ONBOOT=yes
    TYPE=Bridge
    DELAY=0
    DEFROUTE=no
    NM_CONTROLLED=no
    BRIDGING_OPTS='multicast_router=0 multicast_snooping=0'
2. Do 'ifup tar'
3. cat /sys/class/net/tar/bridge/multicast_router

Actual results:
1


Expected results:
0


Additional info:
Adding an 'ip link set dev ${DEVICE} up' solves it for me.

    ***************
    *** 62,67 ****
    --- 62,68 ----
            [ -n "${DELAY}" ] && /usr/sbin/brctl setfd ${DEVICE} ${DELAY}
            [ -n "${STP}" ] && /usr/sbin/brctl stp ${DEVICE} ${STP}
            # add the bits to setup driver parameters here
    +       ip link set dev ${DEVICE} up
            for arg in $BRIDGING_OPTS ; do
                key=${arg%%=*};
                value=${arg##*=};

Comment 1 Antoni Segura Puimedon 2014-04-11 19:10:54 UTC
The code looks the same in fedora, so it happens the same.

Comment 3 Dan Kenigsberg 2014-04-12 21:22:33 UTC
Is it completely safe to take the bridge up (with its default options set) and only later tweak them? (I have flawed STP values in mind)

I'm not sure about the consequence, but please consider re-applying the options after the bridge is up, so that both pre-up and post-up options take effect.

Comment 4 Lukáš Nykrýn 2014-04-14 17:07:26 UTC
We can't set this option because of this check in kernel https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/net/bridge/br_multicast.c?id=refs/tags/v3.15-rc1#n1860

I am not sure why kernel is doing that. They allow to set other parameters when the bridge is down.

Reassigning to kernel to get an opinion if this inconsistency could be fixed in kernel of if we should workaround it in user-space.

Similar issue is with hash_max.

Comment 5 Lukáš Nykrýn 2014-04-14 17:11:33 UTC
By the way bridge-utils have the same problem
[root@localhost ~]# brctl setmcrouter tar 0; echo $?
0
[root@localhost ~]# cat /sys/class/net/tar/bridge/multicast_router
1

Comment 6 Antoni Segura Puimedon 2014-04-14 17:16:04 UTC
It is because certain opts you can only set when the bridge is up, isn't it?

Comment 7 Lukáš Nykrýn 2014-04-14 17:24:48 UTC
But it looks that your reproducer *works* on rhel7.

Comment 8 Lukáš Nykrýn 2014-04-14 17:36:30 UTC
Created attachment 886219 [details]
Completely untested patch which could solve this from initscripts side.

Comment 9 Lukáš Nykrýn 2014-04-29 08:31:34 UTC
Since there is no response from kernel, lets fix it in initscripts.

Comment 12 Dan Kenigsberg 2014-05-09 11:08:29 UTC
Please provide a 6.5.z backport of the fix, as this bug blocks a requested RHEV feature bz 1044042 (to set bridge options).

Comment 16 Dan Kenigsberg 2014-09-24 15:11:21 UTC
Since the fixup patch is tiny, and the bug's resolution is anticipated by a RHEV-3.5 customer, can supporting multicast_snooping be granted exception+?

Comment 17 errata-xmlrpc 2014-10-14 06:28:20 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1448.html

Comment 18 Charles R. Anderson 2015-01-16 22:57:44 UTC
(In reply to Lukáš Nykrýn from comment #10)
> https://git.fedorahosted.org/cgit/initscripts.git/commit/?h=rhel6-
> branch&id=32a67116ad1b2f058d9724b5205a859f01dca7a3

This problem still happens for me, even with the initscripts patch included. Upon initial bootup BRIDGING_OPTS="multicast_snooping=0" doesn't get applied.  Doing another "ifup br0" manually afterwards works.

The patch should be modified to also apply "multicast_snooping", not just "multicast_router" and "hash_max".


Note You need to log in before you can comment on or make changes to this bug.