On 10/12/2015 04:44 PM, Jiri Pirko wrote:
> Mon, Oct 12, 2015 at 04:34:25PM CEST, niko...@cumulusnetworks.com wrote:
>> On 10/12/2015 03:15 PM, Jiri Pirko wrote:
>>> From: Jiri Pirko <j...@mellanox.com>
>>>
>>> Similar to the attr usecase, the caller knows if he is holding RTNL and is
>>> in atomic section. So let the called to decide the correct call variant.
>>>
>>> This allows drivers to sleep inside their ops and wait for hw to get the
>>> operation status. Then the status is propagated into switchdev core.
>>> This avoids silent errors in drivers.
>>>
>>> Signed-off-by: Jiri Pirko <j...@mellanox.com>
>>> ---
>>> include/net/switchdev.h | 1 +
>>> net/switchdev/switchdev.c | 137
>>> +++++++++++++++++++++++++++++++++++++---------
>>> 2 files changed, 112 insertions(+), 26 deletions(-)
>>>
>> [snip]
>>> +
>>> +struct switchdev_obj_work {
>>> + struct work_struct work;
>>> + struct net_device *dev;
>>> + struct switchdev_obj obj;
>>> + bool add; /* add of del */
>> s/of/or/ ? :-)
>
> will fix, thanks.
>
>
>>
>>> +};
>>> +
>>> +static void switchdev_port_obj_work(struct work_struct *work)
>>> +{
>>> + struct switchdev_obj_work *ow =
>>> + container_of(work, struct switchdev_obj_work, work);
>>> + bool rtnl_locked = rtnl_is_locked();
>>> + int err;
>>> +
>>> + if (!rtnl_locked)
>>> + rtnl_lock();
>>> + if (ow->add)
>>> + err = switchdev_port_obj_add_now(ow->dev, &ow->obj);
>>> + else
>>> + err = switchdev_port_obj_del_now(ow->dev, &ow->obj);
>>> + if (err && err != -EOPNOTSUPP)
>>> + netdev_err(ow->dev, "failed (err=%d) to %s object (id=%d)\n",
>>> + err, ow->add ? "add" : "del", ow->obj.id);
>>> + if (!rtnl_locked)
>>> + rtnl_unlock();
>>> +
>>> + dev_put(ow->dev);
>>> + kfree(ow);
>>> +}
>>> +
>>> +static int switchdev_port_obj_work_schedule(struct net_device *dev,
>>> + const struct switchdev_obj *obj,
>>> + bool add)
>>> +{
>>> + struct switchdev_obj_work *ow;
>>> +
>>> + ow = kmalloc(sizeof(*ow), GFP_ATOMIC);
>>> + if (!ow)
>>> + return -ENOMEM;
>>> +
>>> + INIT_WORK(&ow->work, switchdev_port_obj_work);
>>> +
>> This can be called without rtnl, what stops the device from disappearing
>> between the above and the hold below ?
>
> You are right. I will have to figure that out. Btw the same issue
> already exists for attr_set deferred work.
>
>
I have to say there're a few users now that need delayed RTNL execution
the bonding being a heavy one, teaming I think also has some rtnl delays.
Maybe it's time we do a generic delayed rtnl execution so it can be re-used
by all.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
