Netdev List
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Jacob Keller <jacob.e.keller@intel.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
	pabeni@redhat.com, edumazet@google.com, tariqt@nvidia.com,
	saeedm@nvidia.com, gal@nvidia.com, kim.phillips@amd.com,
	moshe@nvidia.com, simon.horman@corigine.com, idosch@nvidia.com
Subject: Re: [patch net-next v2 6/7] devlink: allow to call devl_param_driverinit_value_get() without holding instance lock
Date: Mon, 13 Feb 2023 08:44:40 +0100	[thread overview]
Message-ID: <Y+nqaCfvcbXy0AnN@nanopsycho> (raw)
In-Reply-To: <0a24ce1e-f918-338a-881f-fef2681b250c@intel.com>

Fri, Feb 10, 2023 at 08:41:27PM CET, jacob.e.keller@intel.com wrote:
>
>
>On 2/10/2023 2:01 AM, Jiri Pirko wrote:
>> From: Jiri Pirko <jiri@nvidia.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@intel.com>
>
>Thanks,
>Jake
>
>> 
>> Lore: https://lore.kernel.org/netdev/719de4f0-76ac-e8b9-38a9-167ae239efc7@amd.com/
>> Reported-by: Kim Phillips <kim.phillips@amd.com>
>> Fixes: 075935f0ae0f ("devlink: protect devlink param list by instance lock")
>> Signed-off-by: Jiri Pirko <jiri@nvidia.com>
>> Reviewed-by: Simon Horman <simon.horman@corigine.com>
>> Acked-by: Jakub Kicinski <kuba@kernel.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;
>>  

  reply	other threads:[~2023-02-13  7:44 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-10 10:01 [patch net-next v2 0/7] devlink: params cleanups and devl_param_driverinit_value_get() fix Jiri Pirko
2023-02-10 10:01 ` [patch net-next v2 1/7] devlink: don't use strcpy() to copy param value Jiri Pirko
2023-02-10 19:33   ` Jacob Keller
2023-02-10 10:01 ` [patch net-next v2 2/7] devlink: make sure driver does not read updated driverinit param before reload Jiri Pirko
2023-02-10 10:33   ` Simon Horman
2023-02-10 10:01 ` [patch net-next v2 3/7] devlink: fix the name of value arg of devl_param_driverinit_value_get() Jiri Pirko
2023-02-10 19:35   ` Jacob Keller
2023-02-10 10:01 ` [patch net-next v2 4/7] devlink: use xa_for_each_start() helper in devlink_nl_cmd_port_get_dump_one() Jiri Pirko
2023-02-10 19:36   ` Jacob Keller
2023-02-10 10:01 ` [patch net-next v2 5/7] devlink: convert param list to xarray Jiri Pirko
2023-02-10 19:37   ` Jacob Keller
2023-02-10 10:01 ` [patch net-next v2 6/7] devlink: allow to call devl_param_driverinit_value_get() without holding instance lock Jiri Pirko
2023-02-10 19:41   ` Jacob Keller
2023-02-13  7:44     ` Jiri Pirko [this message]
2023-02-10 22:11   ` Kim Phillips
2023-02-10 10:01 ` [patch net-next v2 7/7] devlink: add forgotten devlink instance lock assertion to devl_param_driverinit_value_set() Jiri Pirko
2023-02-10 19:42   ` Jacob Keller
2023-02-13 10:00 ` [patch net-next v2 0/7] devlink: params cleanups and devl_param_driverinit_value_get() fix patchwork-bot+netdevbpf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y+nqaCfvcbXy0AnN@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=gal@nvidia.com \
    --cc=idosch@nvidia.com \
    --cc=jacob.e.keller@intel.com \
    --cc=kim.phillips@amd.com \
    --cc=kuba@kernel.org \
    --cc=moshe@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=saeedm@nvidia.com \
    --cc=simon.horman@corigine.com \
    --cc=tariqt@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox