All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Jakub Kicinski <kuba@kernel.org>
Cc: jacob.e.keller@intel.com, leon@kernel.org, netdev@vger.kernel.org
Subject: Re: [RFC net-next 04/10] devlink: always check if the devlink instance is registered
Date: Tue, 3 Jan 2023 10:26:12 +0100	[thread overview]
Message-ID: <Y7P0tE3+PyJSwaUC@nanopsycho> (raw)
In-Reply-To: <20230102150514.6321d2ae@kernel.org>

Tue, Jan 03, 2023 at 12:05:14AM CET, kuba@kernel.org wrote:
>On Mon, 2 Jan 2023 14:58:16 +0100 Jiri Pirko wrote:
>> Sat, Dec 17, 2022 at 02:19:47AM CET, kuba@kernel.org wrote:
>> >Always check under the instance lock whether the devlink instance
>> >is still / already registered.
>> >
>> >This is a no-op for the most part, as the unregistration path currently
>> >waits for all references. On the init path, however, we may temporarily
>> >open up a race with netdev code, if netdevs are registered before the
>> >devlink instance. This is temporary, the next change fixes it, and this
>> >commit has been split out for the ease of review.
>> >
>> >Note that in case of iterating over sub-objects which have their
>> >own lock (regions and line cards) we assume an implicit dependency
>> >between those objects existing and devlink unregistration.  
>> 
>> This would be probably very valuable to add as a comment inside the code
>> for the future reader mind sake.
>
>Where, tho?
>
>I'm strongly against the pointlessly fine-grained locking going forward
>so hopefully there won't be any more per-subobject locks added anyway.

Agreed. That is what I suggested in the other thread too.


>
>> >+bool devl_is_alive(struct devlink *devlink)  
>> 
>> Why "alive"? To be consistent with the existing terminology, how about
>> to name it devl_is_registered()?
>
>I dislike the similarity to device_is_registered() which has very
>different semantics. I prefer alive.

Interesting. Didn't occur to me to look into device.h when reading
devlink.c code. I mean, is device_register() behaviour in sync with
devlink_register?

Your alive() helper is checking "register mark". It's an odd and unneded
inconsistency in newly added code :/


>
>> Also, "devl_" implicates that it should be called with devlink instance
>> lock held, so probably devlink_is_registered() would be better.
>
>I'm guessing you realized this isn't correct later on.

From what I see, no need to hold instance mutex for xa mark checking,
alhough I understand why you want the helper to be called with the lock.
Perhaps assert and a little comment would make this clear?


>
>> >+{
>> >+	return xa_get_mark(&devlinks, devlink->index, DEVLINK_REGISTERED);
>> >+}
>> >+EXPORT_SYMBOL_GPL(devl_is_alive);
>> >+
>> >+/**
>> >+ * devlink_try_get() - try to obtain a reference on a devlink instance
>> >+ * @devlink: instance to reference
>> >+ *
>> >+ * Obtain a reference on a devlink instance. A reference on a devlink instance
>> >+ * only implies that it's safe to take the instance lock. It does not imply
>> >+ * that the instance is registered, use devl_is_alive() after taking
>> >+ * the instance lock to check registration status.
>> >+ */  
>> 
>> This comment is not related to the patch, should be added in a separate
>> one.
>
>The point of adding this comment is to say that one has to use
>devl_is_alive() after accessing an instance by reference.
>It is very much in the right patch.

Gotha! My mistake, sorry.



  reply	other threads:[~2023-01-03  9:27 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-17  1:19 [RFC net-next 00/10] devlink: remove the wait-for-references on unregister Jakub Kicinski
2022-12-17  1:19 ` [RFC net-next 01/10] devlink: bump the instance index directly when iterating Jakub Kicinski
2023-01-02 13:24   ` Jiri Pirko
2023-01-02 22:48     ` Jakub Kicinski
2023-01-03  7:35       ` Jiri Pirko
2023-01-04  2:31         ` Jakub Kicinski
2023-01-02 22:56     ` Jakub Kicinski
2022-12-17  1:19 ` [RFC net-next 02/10] devlink: update the code in netns move to latest helpers Jakub Kicinski
2023-01-02 13:45   ` Jiri Pirko
2022-12-17  1:19 ` [RFC net-next 03/10] devlink: protect devlink->dev by the instance lock Jakub Kicinski
2022-12-17  1:19 ` [RFC net-next 04/10] devlink: always check if the devlink instance is registered Jakub Kicinski
2022-12-19 17:48   ` Jacob Keller
2022-12-19 21:55     ` Jakub Kicinski
2022-12-19 22:08       ` Jacob Keller
2023-01-02 13:58   ` Jiri Pirko
2023-01-02 23:05     ` Jakub Kicinski
2023-01-03  9:26       ` Jiri Pirko [this message]
2023-01-04  2:49         ` Jakub Kicinski
2023-01-04 16:14           ` Jiri Pirko
2023-01-02 14:57   ` Jiri Pirko
2023-01-02 15:12     ` Jiri Pirko
2023-01-02 23:16     ` Jakub Kicinski
2023-01-03  9:30       ` Jiri Pirko
2023-01-03 12:26   ` Jiri Pirko
2023-01-04  2:50     ` Jakub Kicinski
2022-12-17  1:19 ` [RFC net-next 05/10] devlink: remove the registration guarantee of references Jakub Kicinski
2022-12-19 17:56   ` Jacob Keller
2022-12-19 22:02     ` Jakub Kicinski
2022-12-19 22:14       ` Jacob Keller
2022-12-19 22:31         ` Jakub Kicinski
2023-01-02 14:18       ` Jiri Pirko
2023-01-02 14:32   ` Jiri Pirko
2023-01-02 23:18     ` Jakub Kicinski
2022-12-17  1:19 ` [RFC net-next 06/10] devlink: don't require setting features before registration Jakub Kicinski
2023-01-02 15:25   ` Jiri Pirko
2023-01-02 23:24     ` Jakub Kicinski
2023-01-02 23:32       ` Jakub Kicinski
2023-01-03  9:46         ` Jiri Pirko
2022-12-17  1:19 ` [RFC net-next 07/10] netdevsim: rename a label Jakub Kicinski
2022-12-19 18:01   ` Jacob Keller
2022-12-17  1:19 ` [RFC net-next 08/10] netdevsim: move devlink registration under the instance lock Jakub Kicinski
2022-12-17  1:19 ` [RFC net-next 09/10] devlink: allow registering parameters after the instance Jakub Kicinski
2022-12-17  1:19 ` [RFC net-next 10/10] netdevsim: register devlink instance before sub-objects Jakub Kicinski
2023-01-02 13:34   ` Jiri Pirko
2023-01-02 23:25     ` Jakub Kicinski
2023-01-03  9:51       ` Jiri Pirko
2023-01-04  2:52         ` Jakub Kicinski
2022-12-19 17:38 ` [RFC net-next 00/10] devlink: remove the wait-for-references on unregister Jacob Keller
2022-12-19 22:10   ` Jakub Kicinski
2022-12-19 22:16     ` Jacob Keller

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=Y7P0tE3+PyJSwaUC@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=jacob.e.keller@intel.com \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=netdev@vger.kernel.org \
    /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.