Received: by 2002:ac0:aed5:0:0:0:0:0 with SMTP id t21csp423214imb; Fri, 1 Mar 2019 04:29:17 -0800 (PST) X-Google-Smtp-Source: APXvYqzYLtbTADwd9IVxUS8YIC0tRmrW3yTTEHgfGtt6f3czlieJYJtFsPg18QXE7ehEg4yEiy6l X-Received: by 2002:a17:902:32b:: with SMTP id 40mr5282423pld.131.1551443357006; Fri, 01 Mar 2019 04:29:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551443356; cv=none; d=google.com; s=arc-20160816; b=Pl/R07X2mEROJFvTlBSpVow/KX1w4M/tuJ/Xa9O84lZMOoWrVUJSJLBlR4TwuJdZHh oU3q4aSug7rmCQOwYecUPkHfQomakrAjjieYlM6y7NFnZD8jZ50qHicmQwbZrqwBfivS /E9Pb9SJHt3IrCfgsX4s4vmCMWTOHOAf46yiRgAhQsOB3EBe/2MXG8KIRdp2Eokv6FDt uRSFqBCHIF4iwGoMNJ3it3iGD+acr8FnsHL13zO9SSvCdHGW6KLHGmxjrlbkI3uwIpVv BUoVW70O0Ku8SOdkb6hVG1IhwXjj+ye09qy7GsaQaX2pnlA1h+H3fBiFQbudo+FOlgue Du2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature; bh=2MagCbawOxkZRtuGDKFunTETA5HAgtt9jb5bH1LAn3M=; b=0AHJP58o0rIh7o5GfOdB/5dNj3Ri/VHTxfIb03kSUJfbYPMjvSmYaHpY7mzxJZzLku YBw0GjobayBqVCxmtOjTDucLrIXZ8Hbkmngw13U6sm67AmcWI7n1E1hS7vH/dPemxWst cPqj036w2n8XtLOV32kfP9DyGQkZlELtyb8Xy7pNiAwMKwbbvhiqRBFWrpx5v5Fn1y8O M+MUPlg9mgVH9AQD1mM1msQurmHXhazktHhAYGnTAZl/2fPRhEAjq8LkzRPZLWA8vce/ MCseiy0BReGGHvgI8X216bC5mtj8fCcoosdEqmIaEWGJdLtvzcj3rRlCl5e8LIfOQ1kZ BNKQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=GkhXi942; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v38si19640218pgn.47.2019.03.01.04.29.01; Fri, 01 Mar 2019 04:29:16 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=GkhXi942; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732514AbfCAM2X (ORCPT + 99 others); Fri, 1 Mar 2019 07:28:23 -0500 Received: from mail-lj1-f196.google.com ([209.85.208.196]:34301 "EHLO mail-lj1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726001AbfCAM2W (ORCPT ); Fri, 1 Mar 2019 07:28:22 -0500 Received: by mail-lj1-f196.google.com with SMTP id l5so20241958lje.1 for ; Fri, 01 Mar 2019 04:28:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=2MagCbawOxkZRtuGDKFunTETA5HAgtt9jb5bH1LAn3M=; b=GkhXi942hnf2O8NEhaFPZv6VOvMz3jP9Kd+DJiZBRxNHDfNvHupeIzFDSvp18wFtZy 7aANYnxISJpfH2v+qSGQgJ7Qm18NiR4FIJIRmPOcKROreJwKCB9ln4WuU5cRacQfl0q1 OAGAH1VwZ9P5cEQvTzGEf1pJSA6smVKoyP0KefGXlE/7CAmS+XWOKXl2V6rLY7HCEhOT WbfqPmBuBslokw660D2Kfz2rZED6lxONNYx9UDfLuZUDzi02Th2sPS4xb+BHQZR/iGN5 EqaTaAeUs4Ym5RnecK2xKWO7fslw+8Khr4VmcdrLSlBGkWWs9fQn0m9XFGucWSHfrc4D Uu9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id :mail-followup-to:references:mime-version:content-disposition :in-reply-to:user-agent; bh=2MagCbawOxkZRtuGDKFunTETA5HAgtt9jb5bH1LAn3M=; b=edG3nqEiVokPtVJWXoF1H72c2yqrdt/5MOnXiCKWHR720Hy83v13nr+hf0qOF1XJSX uDCJgYTDz+GTMpvSyDGy2xqYeIoQyeOdEe/9vYQlpdgsGNzT2CNHzgQLEylshJSmO0ju 10qzCnRKy6yimCtv4UUQ078qWooZ5lp28AlS6DeTpbGxkyyR+7Ss8cg89Jl8pFTee1ti 4ihgc68j/Y31Zc2JswvrlDi5in+rxaAaci6rQjgLREHFRKsikCdPnjpfz5xnVk3TBVq8 /LfakGG1/3dwU8f3NFSKEkdnEGbIG3jYfDqKo2+bWnv6ui7FZrahqySKW4QFqdOzPbKa 6Qyg== X-Gm-Message-State: APjAAAX0oT4EshW1mu+TPldD5dMhla5SUzgFLL+tFFBqrRB5wTNa+5kt sCKsk2lJRzqGaHL5hcGTmCDOdA== X-Received: by 2002:a2e:8496:: with SMTP id b22mr2595496ljh.143.1551443299767; Fri, 01 Mar 2019 04:28:19 -0800 (PST) Received: from khorivan (59-201-94-178.pool.ukrtel.net. [178.94.201.59]) by smtp.gmail.com with ESMTPSA id y2sm4614029lji.46.2019.03.01.04.28.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 01 Mar 2019 04:28:18 -0800 (PST) Date: Fri, 1 Mar 2019 14:28:16 +0200 From: Ivan Khoronzhuk To: Florian Fainelli Cc: davem@davemloft.net, grygorii.strashko@ti.com, linux-omap@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, jiri@mellanox.com, ilias.apalodimas@linaro.org Subject: Re: [PATCH net-next 3/6] net: 8021q: vlan_dev: add vid tag for vlan device own address Message-ID: <20190301122815.GC4851@khorivan> Mail-Followup-To: Florian Fainelli , davem@davemloft.net, grygorii.strashko@ti.com, linux-omap@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, jiri@mellanox.com, ilias.apalodimas@linaro.org References: <20190226184556.16082-1-ivan.khoronzhuk@linaro.org> <20190226184556.16082-4-ivan.khoronzhuk@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 27, 2019 at 08:13:34PM -0800, Florian Fainelli wrote: > > >On 2/26/2019 10:45 AM, Ivan Khoronzhuk wrote: >> The vlan device address is held separately from uc/mc lists and >> handled differently. The vlan dev address is bound with real device >> address only if it's inherited from init, in all other cases it's >> separate address entry in uc list. With vid set, the address becomes >> not inherited from real device after it's set manually as before, but >> is part of uc list any way, with appropriate vid tag set. If vid_len >> for real device is 0, the behaviour is the same as before this change, >> so shouldn't be any impact on systems w/o individual virtual device >> filtering (IVDF) enabled. This allows to control and sync vlan device >> address and disable concrete vlan packet income when vlan interface is >> down. >> >> Signed-off-by: Ivan Khoronzhuk >> --- > >[snip] > >> >> +static int vlan_dev_add_addr(struct net_device *dev, u8 *addr) >> +{ >> + struct net_device *real_dev = vlan_dev_real_dev(dev); >> + unsigned char naddr[ETH_ALEN + NET_8021Q_VID_TSIZE]; >> + >> + if (real_dev->vid_len) { > >Don't you need to check that real_dev->vid_len is >= NET_8021Q_VID_TSIZE >here? vid_len for all eth devices or 0 or NET_8021Q_VID_TSIZE and used here only as a flag that different addressing scheme is used. vlan_dev_set_addr_vid() do copy only < NET_8021Q_VID_TSIZE anyway. Can add the following to be sure: if (real_dev->vid_len) { if (real_dev->vid_len != NET_8021Q_VID_TSIZE) return -1; .... } But frankly, if this happens the system is ill and this check can't help it. > >> + memcpy(naddr, addr, dev->addr_len); >> + vlan_dev_set_addr_vid(dev, naddr); >> + return dev_vid_uc_add(real_dev, naddr); >> + } >> + >> + if (ether_addr_equal(addr, real_dev->dev_addr)) >> + return 0; >> + >> + return dev_uc_add(real_dev, addr); >> +} >> + >> +static void vlan_dev_del_addr(struct net_device *dev, u8 *addr) >> +{ >> + struct net_device *real_dev = vlan_dev_real_dev(dev); >> + unsigned char naddr[ETH_ALEN + NET_8021Q_VID_TSIZE]; >> + >> + if (real_dev->vid_len) { > >Same here. Not same, it's void routine. And del can't happen w/o add, no reason. > >> + memcpy(naddr, addr, dev->addr_len); >> + vlan_dev_set_addr_vid(dev, naddr); >> + dev_vid_uc_del(real_dev, naddr); >> + return; >> + } >> + >> + if (!ether_addr_equal(dev->dev_addr, real_dev->dev_addr)) >> + dev_uc_del(real_dev, addr); >> +} >> + >> +static int vlan_dev_subs_addr(struct net_device *dev, u8 *addr) >> +{ >> + int err; >> + >> + err = vlan_dev_add_addr(dev, addr); >> + if (err < 0) >> + return err; >> + >> + vlan_dev_del_addr(dev, dev->dev_addr); >> + return err; >> +} >> + >> bool vlan_dev_inherit_address(struct net_device *dev, >> struct net_device *real_dev) >> { >> if (dev->addr_assign_type != NET_ADDR_STOLEN) >> return false; >> >> + if (real_dev->vid_len) >> + if (vlan_dev_subs_addr(dev, real_dev->dev_addr)) >> + return false; > >The check on real_dev->vid_len can be absorbed into vlan_dev_subs_addr()? No, I'd tried. vlan_dev_subs_addr() is used not only here and move it under makes more not combined code. > >> + >> ether_addr_copy(dev->dev_addr, real_dev->dev_addr); >> call_netdevice_notifiers(NETDEV_CHANGEADDR, dev); >> return true; >> @@ -278,9 +327,10 @@ static int vlan_dev_open(struct net_device *dev) >> !(vlan->flags & VLAN_FLAG_LOOSE_BINDING)) >> return -ENETDOWN; >> >> - if (!ether_addr_equal(dev->dev_addr, real_dev->dev_addr) && >> - !vlan_dev_inherit_address(dev, real_dev)) { >> - err = dev_uc_add(real_dev, dev->dev_addr); >> + if (ether_addr_equal(dev->dev_addr, real_dev->dev_addr) || >> + (!ether_addr_equal(dev->dev_addr, real_dev->dev_addr) && >> + !vlan_dev_inherit_address(dev, real_dev))) { > >Should this condition simply become if !vlan_dev_inherit_address() now? It can't, I'd tried. vlan_dev_inherit_address() is used in (vlan.c): vlan_sync_address(struct net_device *dev, struct net_device *vlandev); -- Regards, Ivan Khoronzhuk