netdev - Re: [PATCH net-next 2/4] vlan: do not transfer link state in vlan bridge binding mode

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:   Wed, 3 Apr 2019 18:46:47 +0100
From:   Mike Manning <mmanning@...tta.att-mail.com>
To:     Nikolay Aleksandrov <nikolay@...ulusnetworks.com>,
        netdev@...r.kernel.org
Subject: Re: [PATCH net-next 2/4] vlan: do not transfer link state in vlan
 bridge binding mode

On 02/04/2019 21:15, Nikolay Aleksandrov wrote:
> On 02/04/2019 18:35, Mike Manning wrote:
>> In vlan bridge binding mode, the link state is no longer transferred
>> from the lower device. Instead it is set by the bridge module according
>> to the state of bridge ports that are members of the vlan.
>>
>> Signed-off-by: Mike Manning <mmanning@...tta.att-mail.com>
>> ---
>>  net/8021q/vlan.c     | 18 ++++++++++++++----
>>  net/8021q/vlan_dev.c | 19 ++++++++++++-------
>>  2 files changed, 26 insertions(+), 11 deletions(-)
>>
>> diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
>> index dc4411165e43..1f99678751df 100644
>> --- a/net/8021q/vlan.c
>> +++ b/net/8021q/vlan.c
>> @@ -75,6 +75,14 @@ static int vlan_group_prealloc_vid(struct vlan_group *vg,
>>  	return 0;
>>  }
>>  
>> +static void vlan_stacked_transfer_operstate(const struct net_device *rootdev,
>> +					    struct net_device *dev,
>> +					    struct vlan_dev_priv *vlan)
>> +{
>> +	if (!(vlan->flags & VLAN_FLAG_BRIDGE_BINDING))
>> +		netif_stacked_transfer_operstate(rootdev, dev);
>> +}
> I think this may be problematic with STP since STP can set netif_carrier_off() to
> the bridge device even with up ports (but not forwarding) and it will not be propagated
> to the vlan
>
Thanks for catching this issue, I will need to work on a solution for
this before submitting a v1 series (if at all possible). We do not have
this concern with the specific topology for which these changes are
required, but carrier changes due to STP must propagate even with this
option.