linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Vladimir Oltean <olteanv@gmail.com>
To: Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Jakub Kicinski <kuba@kernel.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: DENG Qingfang <dqfext@gmail.com>,
	Tobias Waldekranz <tobias@waldekranz.com>,
	Marek Behun <marek.behun@nic.cz>,
	Russell King - ARM Linux admin <linux@armlinux.org.uk>
Subject: Re: [RFC PATCH net-next 1/3] net: dsa: don't use switchdev_notifier_fdb_info in dsa_switchdev_event_work
Date: Mon, 9 Nov 2020 01:57:02 +0200	[thread overview]
Message-ID: <20201108235702.eoxxekhynkaqnotw@skbuf> (raw)
In-Reply-To: <20201108131953.2462644-2-olteanv@gmail.com>

On Sun, Nov 08, 2020 at 03:19:51PM +0200, Vladimir Oltean wrote:
> diff --git a/net/dsa/slave.c b/net/dsa/slave.c
> index 59c80052e950..30db8230e30b 100644
> --- a/net/dsa/slave.c
> +++ b/net/dsa/slave.c
> @@ -2062,72 +2062,62 @@ static int dsa_slave_netdevice_event(struct notifier_block *nb,
>  	return NOTIFY_DONE;
>  }
>  
> -struct dsa_switchdev_event_work {
> -	struct work_struct work;
> -	struct switchdev_notifier_fdb_info fdb_info;
> -	struct net_device *dev;
> -	unsigned long event;
> -};
> +static void
> +dsa_fdb_offload_notify(struct dsa_switchdev_event_work *switchdev_work)
> +{
> +	struct dsa_switch *ds = switchdev_work->ds;
> +	struct dsa_port *dp = dsa_to_port(ds, switchdev_work->port);
> +	struct switchdev_notifier_fdb_info info;
> +
> +	if (!dsa_is_user_port(ds, dp->index))
> +		return;
> +
> +	info.addr = switchdev_work->addr;
> +	info.vid = switchdev_work->vid;
> +	info.offloaded = true;
> +	call_switchdev_notifiers(SWITCHDEV_FDB_OFFLOADED,
> +				 dp->slave, &info.info, NULL);
> +}
>  
>  static void dsa_slave_switchdev_event_work(struct work_struct *work)
>  {
>  	struct dsa_switchdev_event_work *switchdev_work =
>  		container_of(work, struct dsa_switchdev_event_work, work);
> -	struct net_device *dev = switchdev_work->dev;
> -	struct switchdev_notifier_fdb_info *fdb_info;
> -	struct dsa_port *dp = dsa_slave_to_port(dev);
> +	struct dsa_switch *ds = switchdev_work->ds;
> +	struct dsa_port *dp;
>  	int err;
>  
> +	dp = dsa_to_port(ds, switchdev_work->port);
> +
>  	rtnl_lock();
>  	switch (switchdev_work->event) {
>  	case SWITCHDEV_FDB_ADD_TO_DEVICE:
> -		fdb_info = &switchdev_work->fdb_info;
> -		if (!fdb_info->added_by_user)
> -			break;
> -
> -		err = dsa_port_fdb_add(dp, fdb_info->addr, fdb_info->vid);
> +		err = dsa_port_fdb_add(dp, switchdev_work->addr,
> +				       switchdev_work->vid);
>  		if (err) {
> -			netdev_dbg(dev, "fdb add failed err=%d\n", err);
> +			dev_dbg(ds->dev, "port %d fdb add failed err=%d\n",
> +				dp->index, err);
>  			break;
>  		}
> -		fdb_info->offloaded = true;
> -		call_switchdev_notifiers(SWITCHDEV_FDB_OFFLOADED, dev,
> -					 &fdb_info->info, NULL);
> +		dsa_fdb_offload_notify(switchdev_work);
>  		break;
>  
>  	case SWITCHDEV_FDB_DEL_TO_DEVICE:
> -		fdb_info = &switchdev_work->fdb_info;
> -		if (!fdb_info->added_by_user)
> -			break;
> -
> -		err = dsa_port_fdb_del(dp, fdb_info->addr, fdb_info->vid);
> +		err = dsa_port_fdb_del(dp, switchdev_work->addr,
> +				       switchdev_work->vid);
>  		if (err) {
> -			netdev_dbg(dev, "fdb del failed err=%d\n", err);
> -			dev_close(dev);
> +			dev_dbg(ds->dev, "port %d fdb del failed err=%d\n",
> +				dp->index, err);
> +			if (dsa_is_user_port(ds, dp->index))
> +				dev_close(dp->slave);

Not sure that this dev_close() serves any real purpose, it stands in the
way a little. It was introduced "to indicate inconsistent situation".

commit c9eb3e0f870105242a15a5e628ed202cf32afe0d
Author: Arkadi Sharshevsky <arkadis@mellanox.com>
Date:   Sun Aug 6 16:15:42 2017 +0300

    net: dsa: Add support for learning FDB through notification

    Add support for learning FDB through notification. The driver defers
    the hardware update via ordered work queue. In case of a successful
    FDB add a notification is sent back to bridge.

    In case of hw FDB del failure the static FDB will be deleted from
    the bridge, thus, the interface is moved to down state in order to
    indicate inconsistent situation.

I hope it's ok to only close a net device if it exists, I can't think of
anything smarter.

>  		}
>  		break;
>  	}
>  	rtnl_unlock();
>  
> -	kfree(switchdev_work->fdb_info.addr);
>  	kfree(switchdev_work);
> -	dev_put(dev);
> -}
> -
> -static int
> -dsa_slave_switchdev_fdb_work_init(struct dsa_switchdev_event_work *
> -				  switchdev_work,
> -				  const struct switchdev_notifier_fdb_info *
> -				  fdb_info)
> -{
> -	memcpy(&switchdev_work->fdb_info, fdb_info,
> -	       sizeof(switchdev_work->fdb_info));
> -	switchdev_work->fdb_info.addr = kzalloc(ETH_ALEN, GFP_ATOMIC);
> -	if (!switchdev_work->fdb_info.addr)
> -		return -ENOMEM;
> -	ether_addr_copy((u8 *)switchdev_work->fdb_info.addr,
> -			fdb_info->addr);
> -	return 0;
> +	if (dsa_is_user_port(ds, dp->index))
> +		dev_put(dp->slave);
>  }

The reference counting is broken here. It doesn't line up with the
dev_hold(dev) done in the last patch, which is on a non-DSA interface.
Anyway I think a net_device refcount is way too much for what we need
here, which is to ensure that DSA doesn't get unbound. I think I'll just
simplify to get_device(ds->dev) and put_device(ds->dev).

  reply	other threads:[~2020-11-08 23:57 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-08 13:19 [RFC PATCH net-next 0/3] Offload learnt bridge addresses to DSA Vladimir Oltean
2020-11-08 13:19 ` [RFC PATCH net-next 1/3] net: dsa: don't use switchdev_notifier_fdb_info in dsa_switchdev_event_work Vladimir Oltean
2020-11-08 23:57   ` Vladimir Oltean [this message]
2020-11-08 13:19 ` [RFC PATCH net-next 2/3] net: dsa: move switchdev event implementation under the same switch/case statement Vladimir Oltean
2020-11-11  3:44   ` Florian Fainelli
2020-11-08 13:19 ` [RFC PATCH net-next 3/3] net: dsa: listen for SWITCHDEV_{FDB,DEL}_ADD_TO_DEVICE on foreign bridge neighbors Vladimir Oltean
2020-11-08 14:09   ` DENG Qingfang
2020-11-08 17:23     ` Vladimir Oltean
2020-11-08 23:59       ` Andrew Lunn
2020-11-09  0:30         ` Vladimir Oltean
2020-11-09  1:06           ` Andrew Lunn
2020-11-09  8:09           ` Tobias Waldekranz
2020-11-09 10:03             ` Vladimir Oltean
2020-11-09 11:05               ` Tobias Waldekranz
2020-11-09 12:31                 ` Vladimir Oltean
2020-11-09 12:38                   ` Vladimir Oltean
2020-11-09 12:54                     ` Tobias Waldekranz
2020-11-13  3:48                     ` Florian Fainelli
2020-11-11 10:13       ` Alexandra Winter
2020-11-11 10:36         ` Vladimir Oltean
2020-11-11 14:14           ` Alexandra Winter
2020-11-12 13:49             ` Vladimir Oltean
2020-11-16  8:02               ` Alexandra Winter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201108235702.eoxxekhynkaqnotw@skbuf \
    --to=olteanv@gmail.com \
    --cc=andrew@lunn.ch \
    --cc=dqfext@gmail.com \
    --cc=f.fainelli@gmail.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=marek.behun@nic.cz \
    --cc=netdev@vger.kernel.org \
    --cc=tobias@waldekranz.com \
    --cc=vivien.didelot@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).