linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nikolay Aleksandrov <nikolay@nvidia.com>
To: Vladimir Oltean <olteanv@gmail.com>
Cc: Jakub Kicinski <kuba@kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Andrew Lunn <andrew@lunn.ch>,
	Vivien Didelot <vivien.didelot@gmail.com>,
	Florian Fainelli <f.fainelli@gmail.com>, <netdev@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>,
	<bridge@lists.linux-foundation.org>,
	"Roopa Prabhu" <roopa@nvidia.com>, Jiri Pirko <jiri@resnulli.us>,
	Ido Schimmel <idosch@idosch.org>,
	Claudiu Manoil <claudiu.manoil@nxp.com>,
	"Alexandre Belloni" <alexandre.belloni@bootlin.com>,
	<UNGLinuxDriver@microchip.com>,
	Vadym Kochan <vkochan@marvell.com>,
	Taras Chornyi <tchornyi@marvell.com>,
	Grygorii Strashko <grygorii.strashko@ti.com>,
	Ioana Ciornei <ioana.ciornei@nxp.com>,
	Ivan Vecera <ivecera@redhat.com>, <linux-omap@vger.kernel.org>
Subject: Re: [PATCH v3 net-next 00/11] Cleanup in brport flags switchdev offload for DSA
Date: Wed, 10 Feb 2021 12:52:33 +0200	[thread overview]
Message-ID: <a58e9615-036c-0431-4ea6-004af4988b27@nvidia.com> (raw)
In-Reply-To: <20210210104549.ga3lgjafn5x3htwj@skbuf>

On 10/02/2021 12:45, Vladimir Oltean wrote:
> Hi Nikolay,
> 
> On Wed, Feb 10, 2021 at 12:31:43PM +0200, Nikolay Aleksandrov wrote:
>> Hi Vladimir,
>> Let's take a step back for a moment and discuss the bridge unlock/lock sequences
>> that come with this set. I'd really like to avoid those as they're a recipe
>> for future problems. The only good way to achieve that currently is to keep
>> the PRE_FLAGS call and do that in unsleepable context but move the FLAGS call
>> after the flags have been changed (if they have changed obviously). That would
>> make the code read much easier since we'll have all our lock/unlock sequences
>> in the same code blocks and won't play games to get sleepable context.
>> Please let's think and work in that direction, rather than having:
>> +	spin_lock_bh(&p->br->lock);
>> +	if (err) {
>> +		netdev_err(p->dev, "%s\n", extack._msg);
>> +		return err;
>>  	}
>> +
>>
>> which immediately looks like a bug even though after some code checking we can
>> verify it's ok. WDYT?
>>
>> I plan to get rid of most of the br->lock since it's been abused for a very long
>> time because it's essentially STP lock, but people have started using it for other
>> things and I plan to fix that when I get more time.
> 
> This won't make the sysfs codepath any nicer, will it?
> 

Currently we'll have to live with a hack that checks if the flags have changed. I agree
it won't be pretty, but we won't have to unlock and lock again in the middle of the 
called function and we'll have all our locking in the same place, easier to verify and
later easier to remove. Once I get rid of most of the br->lock usage we can revisit
the drop of PRE_FLAGS if it's a problem. The alternative is to change the flags, then
send the switchdev notification outside of the lock and revert the flags if it doesn't
go through which doesn't sound much better.
I'm open to any other suggestions, but definitely would like to avoid playing locking games.
Even if it means casing out flag setting from all other store_ functions for sysfs.


  reply	other threads:[~2021-02-10 10:56 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-02-10  9:14 [PATCH v3 net-next 00/11] Cleanup in brport flags switchdev offload for DSA Vladimir Oltean
2021-02-10  9:14 ` [PATCH v3 net-next 01/11] net: switchdev: propagate extack to port attributes Vladimir Oltean
2021-02-11  4:12   ` Florian Fainelli
2021-02-10  9:14 ` [PATCH v3 net-next 02/11] net: bridge: offload all port flags at once in br_setport Vladimir Oltean
2021-02-10  9:14 ` [PATCH v3 net-next 03/11] net: bridge: don't print in br_switchdev_set_port_flag Vladimir Oltean
2021-02-10  9:14 ` [PATCH v3 net-next 04/11] net: dsa: configure proper brport flags when ports leave the bridge Vladimir Oltean
2021-02-11  4:16   ` Florian Fainelli
2021-02-10  9:14 ` [PATCH v3 net-next 05/11] net: squash switchdev attributes PRE_BRIDGE_FLAGS and BRIDGE_FLAGS Vladimir Oltean
2021-02-10  9:14 ` [PATCH v3 net-next 06/11] net: dsa: kill .port_egress_floods overengineering Vladimir Oltean
2021-02-11  4:18   ` Florian Fainelli
2021-02-10  9:14 ` [PATCH v3 net-next 07/11] net: prep switchdev drivers for concurrent SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS Vladimir Oltean
2021-02-10 10:12   ` Ido Schimmel
2021-02-10 10:23     ` Vladimir Oltean
2021-02-10 23:34   ` David Miller
2021-02-10  9:14 ` [PATCH v3 net-next 08/11] net: bridge: put SWITCHDEV_ATTR_ID_PORT_BRIDGE_FLAGS on the blocking call chain Vladimir Oltean
2021-02-10 10:14   ` Nikolay Aleksandrov
2021-02-10  9:14 ` [PATCH v3 net-next 09/11] net: mscc: ocelot: use separate flooding PGID for broadcast Vladimir Oltean
2021-02-11  4:19   ` Florian Fainelli
2021-02-10  9:14 ` [PATCH v3 net-next 10/11] net: mscc: ocelot: offload bridge port flags to device Vladimir Oltean
2021-02-11  4:20   ` Florian Fainelli
2021-02-10  9:14 ` [PATCH v3 net-next 11/11] net: dsa: sja1105: " Vladimir Oltean
2021-02-10 10:31 ` [PATCH v3 net-next 00/11] Cleanup in brport flags switchdev offload for DSA Nikolay Aleksandrov
2021-02-10 10:45   ` Vladimir Oltean
2021-02-10 10:52     ` Nikolay Aleksandrov [this message]
2021-02-10 11:01       ` Vladimir Oltean
2021-02-10 11:05         ` Nikolay Aleksandrov
2021-02-10 12:01           ` Vladimir Oltean
2021-02-10 12:10             ` Nikolay Aleksandrov
2021-02-10 12:21             ` Ido Schimmel
2021-02-10 12:29               ` Vladimir Oltean
2021-02-10 12:38                 ` Ido Schimmel
2021-02-10 12:55                   ` Vladimir Oltean
2021-02-10 12:59                     ` Ido Schimmel

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=a58e9615-036c-0431-4ea6-004af4988b27@nvidia.com \
    --to=nikolay@nvidia.com \
    --cc=UNGLinuxDriver@microchip.com \
    --cc=alexandre.belloni@bootlin.com \
    --cc=andrew@lunn.ch \
    --cc=bridge@lists.linux-foundation.org \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=f.fainelli@gmail.com \
    --cc=grygorii.strashko@ti.com \
    --cc=idosch@idosch.org \
    --cc=ioana.ciornei@nxp.com \
    --cc=ivecera@redhat.com \
    --cc=jiri@resnulli.us \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=olteanv@gmail.com \
    --cc=roopa@nvidia.com \
    --cc=tchornyi@marvell.com \
    --cc=vivien.didelot@gmail.com \
    --cc=vkochan@marvell.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).