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=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no 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 39F0DC433DF for ; Thu, 18 Jun 2020 22:46:37 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 04A2D206E2 for ; Thu, 18 Jun 2020 22:46:37 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731275AbgFRWqg (ORCPT ); Thu, 18 Jun 2020 18:46:36 -0400 Received: from vps0.lunn.ch ([185.16.172.187]:47842 "EHLO vps0.lunn.ch" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730004AbgFRWqe (ORCPT ); Thu, 18 Jun 2020 18:46:34 -0400 Received: from andrew by vps0.lunn.ch with local (Exim 4.94) (envelope-from ) id 1jm3Im-001BWM-87; Fri, 19 Jun 2020 00:46:32 +0200 Date: Fri, 19 Jun 2020 00:46:32 +0200 From: Andrew Lunn To: Vladimir Oltean Cc: Cong Wang , netdev , syzbot+f3a0e80c34b3fc28ac5e@syzkaller.appspotmail.com, Taehee Yoo , Dmitry Vyukov Subject: Re: [Patch net] net: change addr_list_lock back to static key Message-ID: <20200618224632.GE279339@lunn.ch> References: <20200608215301.26772-1-xiyou.wangcong@gmail.com> <20200618222959.GC279339@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org > > Hi Vladimir > > > > So you are suggesting this? > > > > > > + ret = netdev_upper_dev_link(master, slave_dev, NULL); > > > > Andrew > > Yes, basically this: > > diff --git a/net/dsa/slave.c b/net/dsa/slave.c > index 4c7f086a047b..6aff8cfc9cf1 100644 > --- a/net/dsa/slave.c > +++ b/net/dsa/slave.c > @@ -1807,6 +1807,13 @@ int dsa_slave_create(struct dsa_port *port) > ret, slave_dev->name); > goto out_phy; > } > + rtnl_lock(); > + ret = netdev_upper_dev_link(master, slave_dev, NULL); > + rtnl_unlock(); > + if (ret) { > + unregister_netdevice(slave_dev); > + goto out_phy; > + } > > return 0; > > @@ -1826,12 +1833,14 @@ int dsa_slave_create(struct dsa_port *port) > > void dsa_slave_destroy(struct net_device *slave_dev) > { > + struct net_device *master = dsa_slave_to_master(slave_dev); > struct dsa_port *dp = dsa_slave_to_port(slave_dev); > struct dsa_slave_priv *p = netdev_priv(slave_dev); > > netif_carrier_off(slave_dev); > rtnl_lock(); > phylink_disconnect_phy(dp->pl); > + netdev_upper_dev_unlink(master, slave_dev); > rtnl_unlock(); > > dsa_slave_notify(slave_dev, DSA_PORT_UNREGISTER); > > Do you see a problem with it? I was initially not sure you could do this. But it looks like you can have N : M relationships between uppers and lowers. I suppose it does make sense. You can have multiple VLAN uppers to one base device. You can have multiple lowers to one bond device, etc. I wonder what 'side effects' there are for declaring this linkage. It is not something i've looked into before, since we never used it. So i don't see a problem with this, other than i don't know what problems we might run into :-) Andrew