[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0a24ce1e-f918-338a-881f-fef2681b250c@intel.com>
Date: Fri, 10 Feb 2023 11:41:27 -0800
From: Jacob Keller <jacob.e.keller@...el.com>
To: Jiri Pirko <jiri@...nulli.us>, <netdev@...r.kernel.org>
CC: <davem@...emloft.net>, <kuba@...nel.org>, <pabeni@...hat.com>,
<edumazet@...gle.com>, <tariqt@...dia.com>, <saeedm@...dia.com>,
<gal@...dia.com>, <kim.phillips@....com>, <moshe@...dia.com>,
<simon.horman@...igine.com>, <idosch@...dia.com>
Subject: Re: [patch net-next v2 6/7] devlink: allow to call
devl_param_driverinit_value_get() without holding instance lock
On 2/10/2023 2:01 AM, Jiri Pirko wrote:
> From: Jiri Pirko <jiri@...dia.com>
>
> If the driver maintains following basic sane behavior, the
> devl_param_driverinit_value_get() function could be called without
> holding instance lock:
>
> 1) Driver ensures a call to devl_param_driverinit_value_get() cannot
> race with registering/unregistering the parameter with
> the same parameter ID.
> 2) Driver ensures a call to devl_param_driverinit_value_get() cannot
> race with devl_param_driverinit_value_set() call with
> the same parameter ID.
> 3) Driver ensures a call to devl_param_driverinit_value_get() cannot
> race with reload operation.
>
> By the nature of params usage, these requirements should be
> trivially achievable. If the driver for some off reason
> is not able to comply, it has to take the devlink->lock while
> calling devl_param_driverinit_value_get().
>
> Remove the lock assertion and add comment describing
> the locking requirements.
>
> This fixes a splat in mlx5 driver introduced by the commit
> referenced in the "Fixes" tag.
Just to clarify, is it possible for mlx5 to take the instance lock
instead of these changes? I agree the improvements make sense here, but
it seems like an alternative fix would be to grab the lock around the
get function call in mlx5.
Either way, the assumptions here seem reasonable and the series makes sense.
Reviewed-by: Jacob Keller <jacob.e.keller@...el.com>
Thanks,
Jake
>
> Lore: https://lore.kernel.org/netdev/719de4f0-76ac-e8b9-38a9-167ae239efc7@amd.com/
> Reported-by: Kim Phillips <kim.phillips@....com>
> Fixes: 075935f0ae0f ("devlink: protect devlink param list by instance lock")
> Signed-off-by: Jiri Pirko <jiri@...dia.com>
> Reviewed-by: Simon Horman <simon.horman@...igine.com>
> Acked-by: Jakub Kicinski <kuba@...nel.org>
> ---
> net/devlink/leftover.c | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/net/devlink/leftover.c b/net/devlink/leftover.c
> index 6d3988f4e843..9f0256c2c323 100644
> --- a/net/devlink/leftover.c
> +++ b/net/devlink/leftover.c
> @@ -9628,14 +9628,23 @@ EXPORT_SYMBOL_GPL(devlink_params_unregister);
> *
> * This function should be used by the driver to get driverinit
> * configuration for initialization after reload command.
> + *
> + * Note that lockless call of this function relies on the
> + * driver to maintain following basic sane behavior:
> + * 1) Driver ensures a call to this function cannot race with
> + * registering/unregistering the parameter with the same parameter ID.
> + * 2) Driver ensures a call to this function cannot race with
> + * devl_param_driverinit_value_set() call with the same parameter ID.
> + * 3) Driver ensures a call to this function cannot race with
> + * reload operation.
> + * If the driver is not able to comply, it has to take the devlink->lock
> + * while calling this.
> */
> int devl_param_driverinit_value_get(struct devlink *devlink, u32 param_id,
> union devlink_param_value *val)
> {
> struct devlink_param_item *param_item;
>
> - lockdep_assert_held(&devlink->lock);
> -
> if (WARN_ON(!devlink_reload_supported(devlink->ops)))
> return -EOPNOTSUPP;
>
Powered by blists - more mailing lists