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.

Powered by blists - more mailing lists