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=-9.5 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 0FFCBC433DB for ; Sat, 9 Jan 2021 04:06:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id CED1B23A69 for ; Sat, 9 Jan 2021 04:06:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726531AbhAIEG0 (ORCPT ); Fri, 8 Jan 2021 23:06:26 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53912 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725861AbhAIEG0 (ORCPT ); Fri, 8 Jan 2021 23:06:26 -0500 Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E05ABC061573 for ; Fri, 8 Jan 2021 20:05:45 -0800 (PST) Received: by mail-pj1-x102e.google.com with SMTP id y12so491006pji.1 for ; Fri, 08 Jan 2021 20:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=kdQkyUxxGDk7qMa1WSeOYT4EhY1gS3x3LZAIiY+B7+M=; b=BiZaTF8N3eaCaPfqD5EyTLLdl7TJuCXbXOQ3BbDN3mmBisAf+Wvd/RTpuBk4JFUM6r Ou/Pe5wQjiOP7NpttoS4QnIt1Plncf1ZX1GJ0J1UKEfsLcMZfNhOYLdtbJsOwohCDaRs CtaAxABB0n9knDpgju9dYoMoQuKp9hwZHM8YN+kMdxnPaRnD+Hn/2adZ3luPShukJuws PwzcBZKFQN7Zc8G/w3Ttdw8Z/20HZF0psPcfT+vB+YNqiFYE51NR/EMIdgMLSaGdoGs2 2mSv9QwhtjC2vbC/jJAbDEsR8hkc5rv/R1VE9hOKXzvhkI7e3fuLRixFcx8AssyPGXMX ByGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=kdQkyUxxGDk7qMa1WSeOYT4EhY1gS3x3LZAIiY+B7+M=; b=sSm3iwllpw2E8ac52cnvneyPJAyTJjppqc90AwNKmVoCf1igDWo6gGgwbF3vQe1r6h FfU5Onh1DfdjEmZjKn8EtTF/Yn51kIIG86XvWvLgmjuPhZXSrlGEVhPkZgm+7C6h5zod 4bEhU80BkzxokMyA5Z5sazdvnUvutXLYqnTsuKiE6mEhem1F/TMCJbgYRrpBUk4LZZ1X vOGKDipfNlS4U5iNe72V+28lmhxr38vR0lbKRWY+rEUPQB4B4cyC40tCPdLE0khhuMP2 xeGIBuHZKyc86s1/b5TNBh7idm8tgPemKIH272TIwd7fpDSZNlLpm4xKaNIL5V76YXhu TSyg== X-Gm-Message-State: AOAM532VPk8vWD7AqNiKW1pl3lx8umfgdDqaGN3gi1Qq75/9/3Ao6w6B coBiKzLyidKHb05w5tlR/S4= X-Google-Smtp-Source: ABdhPJzA+lRexjuRv/mLLJdPrjeRVZpM8dEBujUYtzQkKNSRnXmPI9XJTvD3xRjYdhDE2urDPEob4Q== X-Received: by 2002:a17:902:ed0d:b029:da:c83b:5f40 with SMTP id b13-20020a170902ed0db02900dac83b5f40mr10253451pld.20.1610165145353; Fri, 08 Jan 2021 20:05:45 -0800 (PST) Received: from [10.230.29.29] ([192.19.223.252]) by smtp.gmail.com with ESMTPSA id m4sm10739296pgv.16.2021.01.08.20.05.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Jan 2021 20:05:44 -0800 (PST) Subject: Re: [PATCH v4 net-next 02/11] net: dsa: mv88e6xxx: deny vid 0 on the CPU port and DSA links too To: Vladimir Oltean , "David S. Miller" , Jakub Kicinski , netdev@vger.kernel.org Cc: Andrew Lunn , Vivien Didelot , Kurt Kanzenbach , Hauke Mehrtens , Woojung Huh , Microchip Linux Driver Support , Sean Wang , Landen Chao , Claudiu Manoil , Alexandre Belloni , Linus Walleij , Vadym Kochan , Taras Chornyi , Jiri Pirko , Ido Schimmel , Grygorii Strashko , Ioana Ciornei , Ivan Vecera , Petr Machata References: <20210109000156.1246735-1-olteanv@gmail.com> <20210109000156.1246735-3-olteanv@gmail.com> From: Florian Fainelli Message-ID: Date: Fri, 8 Jan 2021 20:05:41 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <20210109000156.1246735-3-olteanv@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On 1/8/2021 4:01 PM, Vladimir Oltean wrote: > From: Vladimir Oltean > > mv88e6xxx apparently has a problem offloading VID 0, which the 8021q > module tries to install as part of commit ad1afb003939 ("vlan_dev: VLAN > 0 should be treated as "no vlan tag" (802.1p packet)"). That mv88e6xxx > restriction seems to have been introduced by the "VTU GetNext VID-1 > trick to retrieve a single entry" - see commit 2fb5ef09de7c ("net: dsa: > mv88e6xxx: extract single VLAN retrieval"). > > There is one more problem. The mv88e6xxx CPU port and DSA links do not > report properly in the prepare phase what are the VLANs that they can > offload. They'll say they can offload everything: > > mv88e6xxx_port_vlan_prepare > -> mv88e6xxx_port_check_hw_vlan: > > /* DSA and CPU ports have to be members of multiple vlans */ > if (dsa_is_dsa_port(ds, port) || dsa_is_cpu_port(ds, port)) > return 0; > > Except that if you actually try to commit to it, they'll error out and > print this message: > > [ 32.802438] mv88e6085 d0032004.mdio-mii:12: p9: failed to add VLAN 0t > > which comes from: > > mv88e6xxx_port_vlan_add > -> mv88e6xxx_port_vlan_join: > > if (!vid) > return -EOPNOTSUPP; > > What prevents this condition from triggering in real life? The fact that > when a DSA_NOTIFIER_VLAN_ADD is emitted, it never targets a DSA link > directly. Instead, the notifier will always target either a user port or > a CPU port. DSA links just happen to get dragged in by: > > static bool dsa_switch_vlan_match(struct dsa_switch *ds, int port, > struct dsa_notifier_vlan_info *info) > { > ... > if (dsa_is_dsa_port(ds, port)) > return true; > ... > } > > So for every DSA VLAN notifier, during the prepare phase, it will just > so happen that there will be somebody to say "no, don't do that". > > This will become a problem when the switchdev prepare/commit transactional > model goes away. Every port needs to think on its own. DSA links can no > longer bluff and rely on the fact that the prepare phase will not go > through to the end, because there will be no prepare phase any longer. > > Fix this issue before it becomes a problem, by having the "vid == 0" > check earlier than the check whether we are a CPU port / DSA link or not. > Also, the "vid == 0" check becomes unnecessary in the .port_vlan_add > callback, so we can remove it. > > Signed-off-by: Vladimir Oltean Reviewed-by: Florian Fainelli -- Florian