Re: [PATCH net-next v2 5/5] devlink: Delete reload enable/disable interface

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Oct 03, 2021 at 09:12:06PM +0300, Leon Romanovsky wrote:
> From: Leon Romanovsky <leonro@xxxxxxxxxx>
> 
> After changes to allow dynamically set the reload_up/_down callbacks,
> we ensure that properly supported devlink ops are not accessible before
> devlink_register, which is last command in the initialization sequence.
> 
> It makes devlink_reload_enable/_disable not relevant anymore and can be
> safely deleted.
> 
> Signed-off-by: Leon Romanovsky <leonro@xxxxxxxxxx>

[...]

> diff --git a/drivers/net/netdevsim/dev.c b/drivers/net/netdevsim/dev.c
> index cb6645012a30..09e48fb232a9 100644
> --- a/drivers/net/netdevsim/dev.c
> +++ b/drivers/net/netdevsim/dev.c
> @@ -1512,7 +1512,6 @@ int nsim_dev_probe(struct nsim_bus_dev *nsim_bus_dev)
>  
>  	nsim_dev->esw_mode = DEVLINK_ESWITCH_MODE_LEGACY;
>  	devlink_register(devlink);
> -	devlink_reload_enable(devlink);
>  	return 0;
>  
>  err_psample_exit:
> @@ -1566,9 +1565,7 @@ void nsim_dev_remove(struct nsim_bus_dev *nsim_bus_dev)
>  	struct nsim_dev *nsim_dev = dev_get_drvdata(&nsim_bus_dev->dev);
>  	struct devlink *devlink = priv_to_devlink(nsim_dev);
>  
> -	devlink_reload_disable(devlink);
>  	devlink_unregister(devlink);
> -
>  	nsim_dev_reload_destroy(nsim_dev);
>  
>  	nsim_bpf_dev_exit(nsim_dev);

I didn't remember why devlink_reload_{enable,disable}() were added in
the first place so it was not clear to me from the commit message why
they can be removed. It is described in commit a0c76345e3d3 ("devlink:
disallow reload operation during device cleanup") with a reproducer.

Tried the reproducer with this series and I cannot reproduce the issue.
Wasn't quite sure why, but it does not seem to be related to "changes to
allow dynamically set the reload_up/_down callbacks", as this seems to
be specific to mlx5.

IIUC, the reason that the race described in above mentioned commit can
no longer happen is related to the fact that devlink_unregister() is
called first in the device dismantle path, after your previous patches.
Since both the reload operation and devlink_unregister() hold
'devlink_mutex', it is not possible for the reload operation to race
with device dismantle.

Agree? If so, I think it would be good to explain this in the commit
message unless it's clear to everyone else.

Thanks



[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux