From: John Fastabend <john.fastabend@gmail.com>
To: Jiri Pirko <jiri@resnulli.us>, Scott Feldman <sfeldma@gmail.com>
Cc: 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 23:03:46 -0700 [thread overview]
Message-ID: <561C9EC2.7030907@gmail.com> (raw)
In-Reply-To: <20151013054414.GA2242@nanopsycho.orion>
On 15-10-12 10:44 PM, Jiri Pirko wrote:
> Tue, Oct 13, 2015 at 04:52:42AM CEST, sfeldma@gmail.com 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.
>
> If SWITCHDEV_F_DEFER flag is set, there's only 0 of -ENOMEM.
>
>
>>
>>> 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.
>
> Why would someone we call (driver) return the lock? In that case, he is
> buggy and should be fixed.
>
> This hunk only ensures we have rtnl_lock. If not, we take it here. We do
> not take it unconditionally because we may already have it, for example
> if caller of switchdev_flush_deferred holds rtnl_lock.
>
This is where you lost me. How do you know another core doesn't happen
to have the lock when you hit this code path? Maybe someone is running
an ethtool command on another core or something.
next prev parent reply other threads:[~2015-10-13 6:04 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
2015-10-13 5:44 ` Jiri Pirko
2015-10-13 6:03 ` John Fastabend [this message]
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=561C9EC2.7030907@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 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).