All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Jakub Kicinski <kuba@kernel.org>
Cc: netdev@vger.kernel.org, davem@davemloft.net, idosch@nvidia.com,
	petrm@nvidia.com, pabeni@redhat.com, edumazet@google.com,
	mlxsw@nvidia.com, saeedm@nvidia.com, snelson@pensando.io
Subject: Re: [patch net-next v3 01/11] net: devlink: make sure that devlink_try_get() works with valid pointer during xarray iteration
Date: Fri, 22 Jul 2022 08:15:03 +0200	[thread overview]
Message-ID: <YtpAZ6NFPyVmf3At@nanopsycho> (raw)
In-Reply-To: <20220720174953.707bcfa9@kernel.org>

Thu, Jul 21, 2022 at 02:49:53AM CEST, kuba@kernel.org wrote:
>On Wed, 20 Jul 2022 17:12:24 +0200 Jiri Pirko wrote:
>> +static void __devlink_put_rcu(struct rcu_head *head)
>> +{
>> +	struct devlink *devlink = container_of(head, struct devlink, rcu);
>> +
>> +	complete(&devlink->comp);
>> +}
>> +
>>  void devlink_put(struct devlink *devlink)
>>  {
>>  	if (refcount_dec_and_test(&devlink->refcount))
>> -		complete(&devlink->comp);
>> +		/* Make sure unregister operation that may await the completion
>> +		 * is unblocked only after all users are after the end of
>> +		 * RCU grace period.
>> +		 */
>> +		call_rcu(&devlink->rcu, __devlink_put_rcu);
>>  }
>
>Hm. I always assumed we'd just use the xa_lock(). Unmarking the
>instance as registered takes that lock which provides a natural 
>barrier for others trying to take a reference.
>
>Something along these lines (untested):
>
>diff --git a/net/core/devlink.c b/net/core/devlink.c
>index 98d79feeb3dc..6321ea123f79 100644
>--- a/net/core/devlink.c
>+++ b/net/core/devlink.c
>@@ -278,6 +278,38 @@ void devl_unlock(struct devlink *devlink)
> }
> EXPORT_SYMBOL_GPL(devl_unlock);
> 
>+static struct devlink *devlink_iter_next(unsigned long *index)
>+{
>+	struct devlink *devlink;
>+
>+	xa_lock(&devlinks);
>+	devlink = xa_find_after(&devlinks, index, ULONG_MAX,
>+				DEVLINK_REGISTERED);
>+	if (devlink && !refcount_inc_not_zero(&devlink->refcount))
>+		devlink = NULL;
>+	xa_unlock(&devlinks);
>+
>+	return devlink ?: devlink_iter_next(index);
>+}
>+
>+static struct devlink *devlink_iter_start(unsigned long *index)
>+{
>+	struct devlink *devlink;
>+
>+	xa_lock(&devlinks);
>+	devlink = xa_find(&devlinks, index, ULONG_MAX, DEVLINK_REGISTERED);
>+	if (devlink && !refcount_inc_not_zero(&devlink->refcount))
>+		devlink = NULL;
>+	xa_unlock(&devlinks);
>+
>+	return devlink ?: devlink_iter_next(index);
>+}
>+
>+#define devlink_for_each_get(index, entry)			\
>+	for (index = 0, entry = devlink_iter_start(&index);	\
>+	     entry; entry = devlink_iter_next(&index))
>+
> static struct devlink *devlink_get_from_attrs(struct net *net,
> 					      struct nlattr **attrs)
> {
>@@ -1329,10 +1361,7 @@ static int devlink_nl_cmd_rate_get_dumpit(struct sk_buff *msg,
> 	int err = 0;
> 
> 	mutex_lock(&devlink_mutex);
>-	xa_for_each_marked(&devlinks, index, devlink, DEVLINK_REGISTERED) {
>-		if (!devlink_try_get(devlink))
>-			continue;
>-
>+	devlink_for_each_get(index, devlink) {
> 		if (!net_eq(devlink_net(devlink), sock_net(msg->sk)))
> 			goto retry;
> 
>etc.
>
>Plus we need to be more careful about the unregistering order, I
>believe the correct ordering is:
>
>	clear_unmark()
>	put()
>	wait()
>	notify()

Fixed.

>
>but I believe we'll run afoul of Leon's notification suppression.
>So I guess notify() has to go before clear_unmark(), but we should
>unmark before we wait otherwise we could live lock (once the mutex 
>is really gone, I mean).

  parent reply	other threads:[~2022-07-22  6:15 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-20 15:12 [patch net-next v3 00/11] mlxsw: Implement dev info and dev flash for line cards Jiri Pirko
2022-07-20 15:12 ` [patch net-next v3 01/11] net: devlink: make sure that devlink_try_get() works with valid pointer during xarray iteration Jiri Pirko
2022-07-20 22:25   ` Keller, Jacob E
2022-07-21  5:45     ` Jiri Pirko
2022-07-21 18:55       ` Keller, Jacob E
2022-07-22  6:15         ` Jiri Pirko
2022-07-21  0:49   ` Jakub Kicinski
2022-07-21  5:51     ` Jiri Pirko
2022-07-21  6:22       ` Jakub Kicinski
2022-07-21 12:04         ` Jiri Pirko
2022-07-22  6:15     ` Jiri Pirko [this message]
2022-07-22 15:50     ` Jiri Pirko
2022-07-22 18:23       ` Jakub Kicinski
2022-07-23 15:41         ` Jiri Pirko
2022-07-25  8:17           ` Jiri Pirko
2022-07-20 15:12 ` [patch net-next v3 02/11] net: devlink: introduce nested devlink entity for line card Jiri Pirko
2022-07-20 15:12 ` [patch net-next v3 03/11] mlxsw: core_linecards: Introduce per line card auxiliary device Jiri Pirko
2022-07-21  8:04   ` Ido Schimmel
2022-07-20 15:12 ` [patch net-next v3 04/11] mlxsw: core_linecards: Expose HW revision and INI version Jiri Pirko
2022-07-21  8:05   ` Ido Schimmel
2022-07-20 15:12 ` [patch net-next v3 05/11] mlxsw: reg: Extend MDDQ by device_info Jiri Pirko
2022-07-20 15:12 ` [patch net-next v3 06/11] mlxsw: core_linecards: Probe provisioned line cards for devices and expose FW version Jiri Pirko
2022-07-21  8:11   ` Ido Schimmel
2022-07-21 16:01     ` Jiri Pirko
2022-07-20 15:12 ` [patch net-next v3 07/11] mlxsw: reg: Add Management DownStream Device Tunneling Register Jiri Pirko
2022-07-20 15:12 ` [patch net-next v3 08/11] mlxsw: core_linecards: Expose device PSID over device info Jiri Pirko
2022-07-21  8:13   ` Ido Schimmel
2022-07-20 15:12 ` [patch net-next v3 09/11] mlxsw: core_linecards: Implement line card device flashing Jiri Pirko
2022-07-21  8:25   ` Ido Schimmel
2022-07-21 16:01     ` Jiri Pirko
2022-07-20 15:12 ` [patch net-next v3 10/11] selftests: mlxsw: Check line card info on provisioned line card Jiri Pirko
2022-07-20 15:12 ` [patch net-next v3 11/11] selftests: mlxsw: Check line card info on activated " Jiri Pirko

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=YtpAZ6NFPyVmf3At@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=idosch@nvidia.com \
    --cc=kuba@kernel.org \
    --cc=mlxsw@nvidia.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=petrm@nvidia.com \
    --cc=saeedm@nvidia.com \
    --cc=snelson@pensando.io \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.