[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20151015.061022.1838627180852828238.davem@davemloft.net>
Date: Thu, 15 Oct 2015 06:10:22 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: jiri@...nulli.us
Cc: netdev@...r.kernel.org, idosch@...lanox.com, eladr@...lanox.com,
sfeldma@...il.com, f.fainelli@...il.com, linux@...ck-us.net,
vivien.didelot@...oirfairelinux.com, andrew@...n.ch,
john.fastabend@...il.com, David.Laight@...LAB.COM,
stephen@...workplumber.org
Subject: Re: [patch net-next v5 0/8] switchdev: change locking
From: Jiri Pirko <jiri@...nulli.us>
Date: Wed, 14 Oct 2015 19:40:47 +0200
> This is something which I'm currently struggling with.
> Callers of attr_set and obj_add/del often hold not only RTNL, but also
> spinlock (bridge). So in that case, the driver implementing the op cannot sleep.
>
> The way rocker is dealing with this now is just to invoke driver operation
> and go out, without any checking or reporting of the operation status.
>
> Since it would be nice to at least put a warning in case the operation fails,
> it makes sense to do this in delayed work directly in switchdev core
> instead of implementing this in separate drivers. And that is what this patchset
> is introducing.
>
> So from now on, the locking of switchdev mod ops is consistent. Caller either
> holds rtnl mutex or in case it does not, caller sets defer flag, telling
> switchdev core to process the op later, in deferred queue.
>
> Function to force to process switchdev deferred ops can be called by op
> caller in appropriate location, for example after it releases
> spin lock, to force switchdev core to process pending ops.
Series applied, thanks Jiri.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists