All of lore.kernel.org
 help / color / mirror / Atom feed
From: John Fastabend <john.fastabend@gmail.com>
To: Jiri Pirko <jiri@resnulli.us>
Cc: Scott Feldman <sfeldma@gmail.com>,
	Netdev <netdev@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>,
	Ido Schimmel <idosch@mellanox.com>, Elad Raz <eladr@mellanox.com>,
	Florian Fainelli <f.fainelli@gmail.com>,
	Guenter Roeck <linux@roeck-us.net>,
	Vivien Didelot <vivien.didelot@savoirfairelinux.com>,
	"andrew@lunn.ch" <andrew@lunn.ch>,
	David Laight <David.Laight@aculab.com>,
	"stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: Re: [patch net-next v4 2/7] switchdev: allow caller to explicitly request attr_set as deferred
Date: Mon, 12 Oct 2015 22:48:11 -0700	[thread overview]
Message-ID: <561C9B1B.4080408@gmail.com> (raw)
In-Reply-To: <20151013054543.GB2242@nanopsycho.orion>

On 15-10-12 10:45 PM, Jiri Pirko wrote:
> Tue, Oct 13, 2015 at 06:40:25AM CEST, john.fastabend@gmail.com wrote:
>> On 15-10-12 07:52 PM, Scott Feldman wrote:
>>> On Mon, Oct 12, 2015 at 11:03 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>>>> From: Jiri Pirko <jiri@mellanox.com>
>>>>
>>>> Caller should know if he can call attr_set directly (when holding RTNL)
>>>> or if he has to defer the att_set processing for later.
>>>>
>>>> This also allows drivers to sleep inside attr_set and report operation
>>>> status back to switchdev core. Switchdev core then warns if status is
>>>> not ok, instead of silent errors happening in drivers.
>>>>
>>>> Signed-off-by: Jiri Pirko <jiri@mellanox.com>
>>>> ---
>>>>  include/net/switchdev.h   |   1 +
>>>>  net/bridge/br_stp.c       |   3 +-
>>>>  net/switchdev/switchdev.c | 107 ++++++++++++++++++++++++----------------------
>>>>  3 files changed, 59 insertions(+), 52 deletions(-)
>>>>
>>>> diff --git a/include/net/switchdev.h b/include/net/switchdev.h
>>>> index d2879f2..6b109e4 100644
>>>> --- a/include/net/switchdev.h
>>>> +++ b/include/net/switchdev.h
>>>> @@ -17,6 +17,7 @@
>>>>
>>>>  #define SWITCHDEV_F_NO_RECURSE         BIT(0)
>>>>  #define SWITCHDEV_F_SKIP_EOPNOTSUPP    BIT(1)
>>>> +#define SWITCHDEV_F_DEFER              BIT(2)
>>>>
>>>>  struct switchdev_trans_item {
>>>>         struct list_head list;
>>>> diff --git a/net/bridge/br_stp.c b/net/bridge/br_stp.c
>>>> index db6d243de..80c34d7 100644
>>>> --- a/net/bridge/br_stp.c
>>>> +++ b/net/bridge/br_stp.c
>>>> @@ -41,13 +41,14 @@ void br_set_state(struct net_bridge_port *p, unsigned int state)
>>>>  {
>>>>         struct switchdev_attr attr = {
>>>>                 .id = SWITCHDEV_ATTR_ID_PORT_STP_STATE,
>>>> +               .flags = SWITCHDEV_F_DEFER,
>>>>                 .u.stp_state = state,
>>>>         };
>>>>         int err;
>>>>
>>>>         p->state = state;
>>>>         err = switchdev_port_attr_set(p->dev, &attr);
>>>> -       if (err && err != -EOPNOTSUPP)
>>>> +       if (err)
>>>
>>> This looks like a problem as now all other non-switchdev ports will
>>> get an WARN in the log when STP state changes.  We should only WARN if
>>> there was an err and the err is not -EOPNOTSUPP.
>>>
>>>>                 br_warn(p->br, "error setting offload STP state on port %u(%s)\n",
>>>>                                 (unsigned int) p->port_no, p->dev->name);
>>>>  }
>>>
>>> <snip>
>>>
>>>>  struct switchdev_attr_set_work {
>>>>         struct work_struct work;
>>>>         struct net_device *dev;
>>>> @@ -183,14 +226,17 @@ static void switchdev_port_attr_set_work(struct work_struct *work)
>>>>  {
>>>>         struct switchdev_attr_set_work *asw =
>>>>                 container_of(work, struct switchdev_attr_set_work, work);
>>>> +       bool rtnl_locked = rtnl_is_locked();
>>>>         int err;
>>>>
>>>> -       rtnl_lock();
>>>> -       err = switchdev_port_attr_set(asw->dev, &asw->attr);
>>>> +       if (!rtnl_locked)
>>>> +               rtnl_lock();
>>>
>>> I'm not following this change.  If someone else has rtnl_lock, we'll
>>> not wait to grab it here ourselves, and proceed as if we have the
>>> lock.  But what if that someone else releases the lock in the middle
>>> of us doing switchdev_port_attr_set_now?  Seems we want to
>>> unconditionally wait and grab the lock.  We need to block anything
>>> from moving while we do the attr set.
>>>
>>
>> Also an additional race between setting rtnl_locked and the if stmt
>> and then grabbing the lock. There seems to be a something of pattern
>> around this where other subsystems use a rtnl_trylock and if it fails
>> do a restart/re-queue operation to retry. Looks like how you handle
>> it in the team driver at least.
> 
> No, this is for different case. This is for case someone calls
> switchdev_flush_defererd holding the rtnl_lock.
> 

OK rather than funky if stmt could you just do a rtnl_trylock() and
put a comment explaining the reasoning?

  reply	other threads:[~2015-10-13  5:48 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-12 17:54 [patch net-next v4 0/7] switchdev: change locking Jiri Pirko
2015-10-12 17:54 ` [patch net-next v4 1/7] switchdev: introduce switchdev workqueue Jiri Pirko
2015-10-13  3:01   ` Scott Feldman
2015-10-12 18:03 ` [patch net-next v4 2/7] switchdev: allow caller to explicitly request attr_set as deferred Jiri Pirko
2015-10-12 18:03   ` [patch net-next v4 3/7] switchdev: remove pointers from switchdev objects Jiri Pirko
2015-10-13  3:01     ` Scott Feldman
2015-10-13  4:44       ` John Fastabend
2015-10-12 18:03   ` [patch net-next v4 4/7] switchdev: introduce possibility to defer obj_add/del Jiri Pirko
2015-10-13  3:08     ` Scott Feldman
2015-10-12 18:03   ` [patch net-next v4 5/7] bridge: defer switchdev fdb del call in fdb_del_external_learn Jiri Pirko
2015-10-13  3:28     ` Scott Feldman
2015-10-13  3:31       ` John Fastabend
2015-10-13  4:19         ` Scott Feldman
2015-10-13  5:16           ` John Fastabend
2015-10-13  6:05       ` Jiri Pirko
2015-10-13  6:46         ` Scott Feldman
2015-10-12 18:03   ` [patch net-next v4 6/7] rocker: remove nowait from switchdev callbacks Jiri Pirko
2015-10-13  4:02     ` Scott Feldman
2015-10-13  6:25       ` Jiri Pirko
2015-10-13  6:55         ` Scott Feldman
2015-10-12 18:03   ` [patch net-next v4 7/7] switchdev: assert rtnl mutex when going over lower netdevs Jiri Pirko
2015-10-13  2:52   ` [patch net-next v4 2/7] switchdev: allow caller to explicitly request attr_set as deferred Scott Feldman
2015-10-13  4:40     ` John Fastabend
2015-10-13  5:45       ` Jiri Pirko
2015-10-13  5:48         ` John Fastabend [this message]
2015-10-13  5:44     ` Jiri Pirko
2015-10-13  6:03       ` John Fastabend
2015-10-13  6:21         ` Jiri Pirko
2015-10-13  6:53           ` Scott Feldman
2015-10-13  7:30             ` Jiri Pirko
2015-10-13 14:07               ` Scott Feldman
2015-10-13 14:39                 ` Jiri Pirko

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=561C9B1B.4080408@gmail.com \
    --to=john.fastabend@gmail.com \
    --cc=David.Laight@aculab.com \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=eladr@mellanox.com \
    --cc=f.fainelli@gmail.com \
    --cc=idosch@mellanox.com \
    --cc=jiri@resnulli.us \
    --cc=linux@roeck-us.net \
    --cc=netdev@vger.kernel.org \
    --cc=sfeldma@gmail.com \
    --cc=stephen@networkplumber.org \
    --cc=vivien.didelot@savoirfairelinux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.