netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Pirko <jiri@resnulli.us>
To: Shannon Nelson <shnelson@amd.com>
Cc: netdev@vger.kernel.org, davem@davemloft.net, kuba@kernel.org,
	pabeni@redhat.com, edumazet@google.com,
	michael.chan@broadcom.com, ioana.ciornei@nxp.com,
	dmichail@fungible.com, jesse.brandeburg@intel.com,
	anthony.l.nguyen@intel.com, tchornyi@marvell.com,
	tariqt@nvidia.com, saeedm@nvidia.com, leon@kernel.org,
	idosch@nvidia.com, petrm@nvidia.com, vladimir.oltean@nxp.com,
	claudiu.manoil@nxp.com, alexandre.belloni@bootlin.com,
	simon.horman@corigine.com, shannon.nelson@amd.com,
	brett.creeley@amd.com
Subject: Re: [patch net-next 1/8] devlink: call devlink_port_register/unregister() on registered instance
Date: Wed, 7 Dec 2022 14:27:48 +0100	[thread overview]
Message-ID: <Y5CU1DkXVRoz3PcQ@nanopsycho> (raw)
In-Reply-To: <a5c5b1f9-60e9-6e82-911e-03e56ff42da1@amd.com>

Tue, Dec 06, 2022 at 06:35:32PM CET, shnelson@amd.com wrote:
>On 12/5/22 11:41 PM, Jiri Pirko wrote:
>> Tue, Dec 06, 2022 at 12:55:32AM CET, shnelson@amd.com wrote:
>> > On 12/5/22 7:22 AM, Jiri Pirko wrote:
>> > > 
>> > > From: Jiri Pirko <jiri@nvidia.com>
>> > > 
>> > > Change the drivers that use devlink_port_register/unregister() to call
>> > > these functions only in case devlink is registered.
>
>
>> > 
>> > I haven't kept up on all the discussion about this, but is there no longer a
>> > worry about registering the devlink object before all the related
>> > configuration bits are in place?
>> > 
>> > Does this open any potential issues with userland programs seeing the devlink
>> > device and trying to access port before they get registered?
>> 
>> What exactly do you have in mind? Could you please describe it?
>
>It looks like this could be setting up a race condition that some userland
>udev automation might hit if it notices the device, looks for the port, but
>doesn't see the port yet.  Leon's patch turned this around so that the ports
>would show up at the same time as the device.

Any userland automation should not rely on that. Ports may come and go
with the current code as well, see port split/unsplit, linecard
provision unprovision.

  reply	other threads:[~2022-12-07 13:27 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-05 15:22 [patch net-next 0/8] devlink: make sure devlink port registers/unregisters only for registered instance Jiri Pirko
2022-12-05 15:22 ` [patch net-next 1/8] devlink: call devlink_port_register/unregister() on " Jiri Pirko
2022-12-05 23:55   ` Shannon Nelson
2022-12-06  7:41     ` Jiri Pirko
2022-12-06  7:56       ` Leon Romanovsky
2022-12-06 17:35       ` Shannon Nelson
2022-12-07 13:27         ` Jiri Pirko [this message]
2022-12-07 19:45           ` Shannon Nelson
2022-12-05 15:22 ` [patch net-next 2/8] netdevsim: call devl_port_register/unregister() " Jiri Pirko
2022-12-05 15:22 ` [patch net-next 3/8] mlxsw: " Jiri Pirko
2022-12-05 15:22 ` [patch net-next 4/8] nfp: " Jiri Pirko
2022-12-05 15:22 ` [patch net-next 5/8] mlx4: " Jiri Pirko
2022-12-05 15:22 ` [patch net-next 6/8] mlx5: " Jiri Pirko
2022-12-05 15:22 ` [patch net-next 7/8] devlink: assert if devl_port_register/unregister() is called on unregistered devlink instance Jiri Pirko
2022-12-05 15:22 ` [patch net-next 8/8] devlink: remove port notifications from devlink_register/unregister() Jiri Pirko
2022-12-06  1:08 ` [patch net-next 0/8] devlink: make sure devlink port registers/unregisters only for registered instance Jakub Kicinski
2022-12-06  7:44   ` Jiri Pirko
2022-12-06 20:12     ` Jakub Kicinski
2022-12-07 13:28       ` 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=Y5CU1DkXVRoz3PcQ@nanopsycho \
    --to=jiri@resnulli.us \
    --cc=alexandre.belloni@bootlin.com \
    --cc=anthony.l.nguyen@intel.com \
    --cc=brett.creeley@amd.com \
    --cc=claudiu.manoil@nxp.com \
    --cc=davem@davemloft.net \
    --cc=dmichail@fungible.com \
    --cc=edumazet@google.com \
    --cc=idosch@nvidia.com \
    --cc=ioana.ciornei@nxp.com \
    --cc=jesse.brandeburg@intel.com \
    --cc=kuba@kernel.org \
    --cc=leon@kernel.org \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=petrm@nvidia.com \
    --cc=saeedm@nvidia.com \
    --cc=shannon.nelson@amd.com \
    --cc=shnelson@amd.com \
    --cc=simon.horman@corigine.com \
    --cc=tariqt@nvidia.com \
    --cc=tchornyi@marvell.com \
    --cc=vladimir.oltean@nxp.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;
as well as URLs for NNTP newsgroup(s).