[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Y+nqaCfvcbXy0AnN@nanopsycho>
Date: Mon, 13 Feb 2023 08:44:40 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Jacob Keller <jacob.e.keller@...el.com>
Cc: netdev@...r.kernel.org, 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
Fri, Feb 10, 2023 at 08:41:27PM CET, jacob.e.keller@...el.com wrote:
>
>
>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.
You are correct, yes.
>
>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