netdev - Re: [Bug 194749] New: kernel bonding does not work in a network nameservice in versions above 3.10.0-229.20.1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 3 Mar 2017 16:19:13 +0100
From:   Nicolas Dichtel <nicolas.dichtel@...nd.com>
To:     Dan Geist <dan@...ter.net>, Cong Wang <xiyou.wangcong@...il.com>
Cc:     Stephen Hemminger <stephen@...workplumber.org>,
        Linux Kernel Network Developers <netdev@...r.kernel.org>,
        chenweilong@...wei.com, Jiri Pirko <jiri@...lanox.com>
Subject: Re: [Bug 194749] New: kernel bonding does not work in a network
 nameservice in versions above 3.10.0-229.20.1

Le 02/03/2017 à 21:39, Dan Geist a écrit :
> ----- On Mar 2, 2017, at 3:11 PM, Cong Wang xiyou.wangcong@...il.com wrote
> 
>> On Thu, Mar 2, 2017 at 10:32 AM, Stephen Hemminger
>> <stephen@...workplumber.org> wrote:
>>>
>>>
>>> Begin forwarded message:
>>>
>>> Date: Wed, 01 Mar 2017 21:08:01 +0000
>>> From: bugzilla-daemon@...zilla.kernel.org
>>> To: stephen@...workplumber.org
>>> Subject: [Bug 194749] New: kernel bonding does not work in a network nameservice
>>> in versions above 3.10.0-229.20.1
>>>
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=194749
>>>
>>>             Bug ID: 194749
>>>            Summary: kernel bonding does not work in a network nameservice
>>>                     in versions above 3.10.0-229.20.1
>>>            Product: Networking
>>>            Version: 2.5
>>>     Kernel Version: > 3.10.0-229.20.1
>>>           Hardware: x86-64
>>>                 OS: Linux
>>>               Tree: Mainline
>>>             Status: NEW
>>>           Severity: blocking
>>>           Priority: P1
>>>          Component: Other
>>>           Assignee: stephen@...workplumber.org
>>>           Reporter: dan@...ter.net
>>>         Regression: No
>>>
>>> bond interface is being used in active/standby mode with two physical NICs
>>> inside a network nameservice to provide switchpath redundancy.
>>>
>>> netns is instantiated post-boot with the following:
>>>
>>> ip netns add vntp
>>> ip link set p4p1 netns vntp
>>> ip link set p4p2 netns vntp
>>> ip link set bond0 netns vntp
>>> ip netns exec vntp ip link set lo up
>>> ip netns exec vntp ip link set p4p1 up
>>> ip netns exec vntp ip link set p4p2 up
>>> ip netns exec vntp ip link set bond0 up
>>> ip netns exec vntp ifenslave bond0 p4p1 p4p2
>>
>> This is due to the following commit:
>>
>> commit f9399814927ad9bb995a6e109c2a5f9d8a848209
>> Author: Weilong Chen <chenweilong@...wei.com>
>> Date:   Wed Jan 22 17:16:30 2014 +0800
>>
>>    bonding: Don't allow bond devices to change network namespaces.
>>
>>    Like bridge, bonding as netdevice doesn't cross netns boundaries.
>>
>>    Bonding ports and bonding itself live in same netns.
>>
>>    Signed-off-by: Weilong Chen <chenweilong@...wei.com>
>>    Signed-off-by: David S. Miller <davem@...emloft.net>
>>
>>
>> NETIF_F_NETNS_LOCAL was introduced for loopback device which
>> is created for each netns, it is not clear why we need to add it to bond
>> and bridge...
> 
> Thank you for tracking this down. Without digging through the code to figure it out, does this imply that the existence of a bond interface is not possible AT ALL within a netns or simply that it may not be "migrated" between the global scope and a netns?
It means that the migration is not possible. I think the only reason to have
this flag on bonding and bridge is the lack of test and fix. There is probably
some work to be done to have this feature. But are there real use cases of
x-netns bonding or x-netns bridge?