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.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH,MAILING_LIST_MULTI, SIGNED_OFF_BY,SPF_PASS 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 46B40C4360F for ; Tue, 2 Apr 2019 20:13:20 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 087B62070D for ; Tue, 2 Apr 2019 20:13:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=cumulusnetworks.com header.i=@cumulusnetworks.com header.b="XYcFmf85" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1725990AbfDBUNS (ORCPT ); Tue, 2 Apr 2019 16:13:18 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:51155 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725822AbfDBUNS (ORCPT ); Tue, 2 Apr 2019 16:13:18 -0400 Received: by mail-wm1-f66.google.com with SMTP id z11so4859370wmi.0 for ; Tue, 02 Apr 2019 13:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cumulusnetworks.com; s=google; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=5er7gmv3PFvqCaKgB2OEwiNfsTTsJr40pvoYAyiXF7k=; b=XYcFmf85/jSzUIoDBw21UOlIi5P46CsjQ6eOAkx14xiPihhZvB6ed8qHW/NM8Ul44P VdZtPqgqFpZx0liLPIsCiy+xXf0P4WCtankbiL+Jl82NOVWs5ewjAgBqFj3sepBq1qhu psnEZBTBYfFYsIiFomhH6ZN2WVf+OAx74pd5U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=5er7gmv3PFvqCaKgB2OEwiNfsTTsJr40pvoYAyiXF7k=; b=Nw811ExNNizLSdPzc4FX8dixp1j1thDXa3kWKQehQiZKJD+k7SnkQEyYXYgTRsod68 mwstRPtkpT8+lxmCeuO+rnwHm6b3uaKLvbcVhAJVkO8VJDoPP7lEc+8OlyLusmlu+Luw PSSLmN2xi0Yaudw4LHNLz98ldpW0oSHhkCQL2QuE1J7JbzkawFmBf4ogHbRU/nXS3Vz9 T9oE7f1UewlW37qfwzB+FqBsM6S4AwMkfhhHXnS5q9Nwjf5kusQzKadiYAMH4JvjxT2f pqEriP7Cz06GWAc17m/DFy7DHLUne/aQDf1tlW0aoo/3C0RCL82uNNIqXFhb2gk03B/V fheg== X-Gm-Message-State: APjAAAXo2zeIsCfvuZ2pAPj65oAcehK/zuuplj3sjohE6+lL9oX+wl3+ PBmu3vrYA1TTUFh5CSTXOH61aQZGKQoUDQ== X-Google-Smtp-Source: APXvYqzqDFxMpmZfU4D1Y4fhWhbAJ1GkOi9DKld1Z1AYyuyL+avEur+/NTbGtWcTOScfUs5d8ODP2A== X-Received: by 2002:a7b:c347:: with SMTP id l7mr4814037wmj.70.1554235996429; Tue, 02 Apr 2019 13:13:16 -0700 (PDT) Received: from [192.168.0.107] (84-238-136-197.ip.btc-net.bg. [84.238.136.197]) by smtp.gmail.com with ESMTPSA id c189sm18850589wme.32.2019.04.02.13.13.14 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 02 Apr 2019 13:13:15 -0700 (PDT) Subject: Re: [PATCH net-next 1/4] vlan: support binding link state to vlan member bridge ports From: Nikolay Aleksandrov To: Mike Manning , netdev@vger.kernel.org References: <20190402153543.6277-1-mmanning@vyatta.att-mail.com> <20190402153543.6277-2-mmanning@vyatta.att-mail.com> Message-ID: Date: Tue, 2 Apr 2019 23:13:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 02/04/2019 22:20, Nikolay Aleksandrov wrote: > On 02/04/2019 18:35, Mike Manning wrote: >> In the case of vlan filtering on bridges, the bridge may also have the >> corresponding vlan devices as upper devices. Currently the link state >> of vlan devices is transferred from the lower device. So this is up if >> the bridge is in admin up state and there is at least one bridge port >> that is up, regardless of the vlan that the port is a member of. >> >> The link state of the vlan device may need to track only the state of >> the subset of ports that are also members of the corresponding vlan, >> rather than that of all ports. >> >> Add a flag to specify a vlan bridge binding mode, by which the link >> state is no longer automatically transferred from the lower device, >> but is instead determined by the bridge ports that are members of the >> vlan. >> >> Signed-off-by: Mike Manning >> --- >> include/uapi/linux/if_vlan.h | 9 +++++---- >> net/8021q/vlan_dev.c | 3 ++- >> net/8021q/vlan_netlink.c | 3 ++- >> 3 files changed, 9 insertions(+), 6 deletions(-) >> > > What if the following happens: > 1. add binding vlan X on bridge > 2. no up vlan ports for X > 3. set no carrier on vlan X > 4. remove binding flag on X > > Would vlan X remain in no carrier state ? > Ah patch 02 arrived much later, I think this should be fine. :) >> diff --git a/include/uapi/linux/if_vlan.h b/include/uapi/linux/if_vlan.h >> index 7a0e8bd65b6b..601931ac8002 100644 >> --- a/include/uapi/linux/if_vlan.h >> +++ b/include/uapi/linux/if_vlan.h >> @@ -32,10 +32,11 @@ enum vlan_ioctl_cmds { >> }; >> >> enum vlan_flags { >> - VLAN_FLAG_REORDER_HDR = 0x1, >> - VLAN_FLAG_GVRP = 0x2, >> - VLAN_FLAG_LOOSE_BINDING = 0x4, >> - VLAN_FLAG_MVRP = 0x8, >> + VLAN_FLAG_REORDER_HDR = 0x1, >> + VLAN_FLAG_GVRP = 0x2, >> + VLAN_FLAG_LOOSE_BINDING = 0x4, >> + VLAN_FLAG_MVRP = 0x8, >> + VLAN_FLAG_BRIDGE_BINDING = 0x16, >> }; >> >> enum vlan_name_types { >> diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c >> index 15293c2a5dd8..86b38bb87f9a 100644 >> --- a/net/8021q/vlan_dev.c >> +++ b/net/8021q/vlan_dev.c >> @@ -223,7 +223,8 @@ int vlan_dev_change_flags(const struct net_device *dev, u32 flags, u32 mask) >> u32 old_flags = vlan->flags; >> >> if (mask & ~(VLAN_FLAG_REORDER_HDR | VLAN_FLAG_GVRP | >> - VLAN_FLAG_LOOSE_BINDING | VLAN_FLAG_MVRP)) >> + VLAN_FLAG_LOOSE_BINDING | VLAN_FLAG_MVRP | >> + VLAN_FLAG_BRIDGE_BINDING)) >> return -EINVAL; >> >> vlan->flags = (old_flags & ~mask) | (flags & mask); >> diff --git a/net/8021q/vlan_netlink.c b/net/8021q/vlan_netlink.c >> index 9b60c1e399e2..a624dccf68fd 100644 >> --- a/net/8021q/vlan_netlink.c >> +++ b/net/8021q/vlan_netlink.c >> @@ -84,7 +84,8 @@ static int vlan_validate(struct nlattr *tb[], struct nlattr *data[], >> flags = nla_data(data[IFLA_VLAN_FLAGS]); >> if ((flags->flags & flags->mask) & >> ~(VLAN_FLAG_REORDER_HDR | VLAN_FLAG_GVRP | >> - VLAN_FLAG_LOOSE_BINDING | VLAN_FLAG_MVRP)) { >> + VLAN_FLAG_LOOSE_BINDING | VLAN_FLAG_MVRP | >> + VLAN_FLAG_BRIDGE_BINDING)) { >> NL_SET_ERR_MSG_MOD(extack, "Invalid VLAN flags"); >> return -EINVAL; >> } >> >