netdev - Re: [PATCH net-next] net/ipv6: Block IPv6 addrconf on team ports

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] [day] [month] [year] [list]

Date:   Fri, 26 Oct 2018 08:01:06 +0200
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jay Vosburgh <jay.vosburgh@...onical.com>
Cc:     Chas Williams <3chas3@...il.com>, davem@...emloft.net,
        netdev@...r.kernel.org, vfalico@...il.com, andy@...yhouse.net,
        kuznet@....inr.ac.ru, yoshfuji@...ux-ipv6.org
Subject: Re: [PATCH net-next] net/ipv6: Block IPv6 addrconf on team ports

Fri, Oct 26, 2018 at 12:40:31AM CEST, jay.vosburgh@...onical.com wrote:
>Chas Williams <3chas3@...il.com> wrote:
>
>>On 10/25/2018 05:59 PM, Jay Vosburgh wrote:
>>> Chas Williams <3chas3@...il.com> wrote:
>>>
>>>> netif_is_lag_port should be used to identify link aggregation ports.
>>>> For this to work, we need to reorganize the bonding and team drivers
>>>> so that the necessary flags are set before dev_open is called.
>>>>
>>>> commit 31e77c93e432 ("sched/fair: Update blocked load when newly idle")
>>>> made this decision originally based on the IFF_SLAVE flag which isn't
>>>> used by the team driver.  Note, we do need to retain the IFF_SLAVE
>>>> check for the eql driver.
>>>
>>> 	Is 31e77c93e432 the correct commit reference?  I don't see
>>> anything in there about IFF_SLAVE or bonding; it's a patch to the
>>> process scheduler.
>>
>>No, that's wrong.  It should be c2edacf80e155.
>>
>>> 	And, as Jiri said, the subject doesn't mention bonding.
>>
>>The behavior of bonding wasn't changed.  The intent of the patch
>>is to add team slaves to the interfaces that don't get automatic
>>IPv6 addresses.  The body discusses why bonding had to change as
>>well.
>
>	Sure, but the bonding code has changed, and the current
>presentation makes it harder for reviewers to follow (or perhaps even
>notice).
>
>>I was under the impression that the subject needs to kept short.
>>If there a better way to phrase what I want to do?
>
>	I'd suggest splitting this into three patches: A first patch
>that adds the new IPv6 functionality, then one patch each for team and
>bonding to take advantage of that new functionality.  Each of the three
>would then be very straightforward, change just one thing, and should be
>clearer all around.

+1