From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 61516C4360F for ; Wed, 3 Apr 2019 17:47:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 194992084B for ; Wed, 3 Apr 2019 17:47:50 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726372AbfDCRrt (ORCPT ); Wed, 3 Apr 2019 13:47:49 -0400 Received: from mx0b-00191d01.pphosted.com ([67.231.157.136]:38316 "EHLO mx0a-00191d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726097AbfDCRrs (ORCPT ); Wed, 3 Apr 2019 13:47:48 -0400 Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x33HPnGn006223; Wed, 3 Apr 2019 13:47:46 -0400 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049459.ppops.net-00191d01. with ESMTP id 2rn026365k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 03 Apr 2019 13:47:26 -0400 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id x33HkwAT056978; Wed, 3 Apr 2019 12:46:59 -0500 Received: from zlp30493.vci.att.com (zlp30493.vci.att.com [135.46.181.176]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id x33HkuAh056896 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 3 Apr 2019 12:46:56 -0500 Received: from zlp30493.vci.att.com (zlp30493.vci.att.com [127.0.0.1]) by zlp30493.vci.att.com (Service) with ESMTP id 1FFA040470A1; Wed, 3 Apr 2019 17:46:56 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30493.vci.att.com (Service) with ESMTP id E264340470A0; Wed, 3 Apr 2019 17:46:55 +0000 (GMT) Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id x33HktQn030135; Wed, 3 Apr 2019 12:46:55 -0500 Received: from mail.eng.vyatta.net (mail.eng.vyatta.net [10.156.50.82]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id x33HknvJ029839; Wed, 3 Apr 2019 12:46:49 -0500 Received: from [10.156.47.138] (unknown [10.156.47.138]) by mail.eng.vyatta.net (Postfix) with ESMTPA id DE5413600D9; Wed, 3 Apr 2019 10:46:48 -0700 (PDT) Reply-To: mmanning@vyatta.att-mail.com Subject: Re: [PATCH net-next 2/4] vlan: do not transfer link state in vlan bridge binding mode To: Nikolay Aleksandrov , netdev@vger.kernel.org References: <20190402153543.6277-1-mmanning@vyatta.att-mail.com> <20190402153543.6277-3-mmanning@vyatta.att-mail.com> <358a0759-e2be-52e7-eabd-928c678cb06d@cumulusnetworks.com> From: Mike Manning Message-ID: Date: Wed, 3 Apr 2019 18:46:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <358a0759-e2be-52e7-eabd-928c678cb06d@cumulusnetworks.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-04-03_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904030118 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org 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 >> --- >> 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.