Re: [PATCH net-next] devlink: Require devlink lock during device reload

From
Ido Schimmel <hidden>
Date
2021-11-01 07:12:29
Also in
lkml
Reply to
Leon Romanovsky, 2021-10-31
On Sun, Oct 31, 2021 at 07:35:56PM +0200, Leon Romanovsky wrote:
From: Leon Romanovsky <leonro@nvidia.com>

Devlink reload was implemented as a special command which does _SET_
operation, but doesn't take devlink->lock, while recursive devlink
calls that were part of .reload_up()/.reload_down() sequence took it.

This fragile flow was possible due to holding a big devlink lock
(devlink_mutex), which effectively stopped all devlink activities,
even unrelated to reloaded devlink.

So let's make sure that devlink reload behaves as other commands and
use special nested locking primitives with a depth of 1. Such change
opens us to a venue of removing devlink_mutex completely, while keeping
devlink locking complexity in devlink.c.
Jakub/Dave, I will be mostly unavailable until later this week, but I
have applied this patch to our queue and can report testing results
tomorrow. I would appreciate it if you could hold off on applying it
until then.

Thanks
Thread (42 messages) 42 messages, 5 authors, last reply 2021-11-17
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help