All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jakub Kicinski <kuba@kernel.org>
To: Jiri Pirko <jiri@resnulli.us>
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: Wed, 20 Jul 2022 23:22:58 -0700	[thread overview]
Message-ID: <20220720232258.22139059@kernel.org> (raw)
In-Reply-To: <YtjpaRtkOwX00azI@nanopsycho>

On Thu, 21 Jul 2022 07:51:37 +0200 Jiri Pirko wrote:
> >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.  
> 
> I guess that the xa_lock() scheme could work, as far as I see it. But
> what's wrong with the rcu scheme? I actually find it quite neat. No need
> to have another odd iteration helpers. We just benefit of xa_array rcu
> internals to make sure devlink pointer is valid at the time we make a
> reference. Very clear.

Nothing strongly against the RCU scheme, TBH. Just didn't expect it.
I can concoct some argument like it's one extra sync primitive we
haven't had to think about in devlink so far, but really if you prefer
RCU, I don't mind.

I do like the idea of wrapping the iteration into our own helper, tho.
Contains the implementation details of the iteration nicely. I didn't
look in sufficient detail but I would have even considered rolling the
namespace check into it for dump.

  reply	other threads:[~2022-07-21  6:23 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 [this message]
2022-07-21 12:04         ` Jiri Pirko
2022-07-22  6:15     ` Jiri Pirko
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=20220720232258.22139059@kernel.org \
    --to=kuba@kernel.org \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=idosch@nvidia.com \
    --cc=jiri@resnulli.us \
    --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.