[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20221205170826.17c78e90@kernel.org>
Date: Mon, 5 Dec 2022 17:08:26 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: netdev@...r.kernel.org, davem@...emloft.net, pabeni@...hat.com,
edumazet@...gle.com, michael.chan@...adcom.com,
ioana.ciornei@....com, dmichail@...gible.com,
jesse.brandeburg@...el.com, anthony.l.nguyen@...el.com,
tchornyi@...vell.com, tariqt@...dia.com, saeedm@...dia.com,
leon@...nel.org, idosch@...dia.com, petrm@...dia.com,
vladimir.oltean@....com, claudiu.manoil@....com,
alexandre.belloni@...tlin.com, simon.horman@...igine.com,
shannon.nelson@....com, brett.creeley@....com
Subject: Re: [patch net-next 0/8] devlink: make sure devlink port
registers/unregisters only for registered instance
On Mon, 5 Dec 2022 16:22:49 +0100 Jiri Pirko wrote:
> Currently, the devlink_register() is called as the last thing during
> driver init phase. For devlink objects, this is fine as the
> notifications of objects creations are withheld to be send only after
> devlink instance is registered. Until devlink is registered it is not
> visible to userspace.
>
> But if a netdev is registered before, user gets a notification with
> a link to devlink, which is not visible to the user yet.
> This is the event order user sees:
> * new netdev event over RT netlink
> * new devlink event over devlink netlink
> * new devlink_port event over devlink netlink
>
> Also, this is not consistent with devlink port split or devlink reload
> flows, where user gets notifications in following order:
> * new devlink event over devlink netlink
> and then during port split or reload operation:
> * new devlink_port event over devlink netlink
> * new netdev event over RT netlink
>
> In this case, devlink port and related netdev are registered on already
> registered devlink instance.
>
> Purpose of this patchset is to fix the drivers init flow so devlink port
> gets registered only after devlink instance is registered.
I didn't reply because I don't have much to add beyond what
I've already said too many times. I prefer to move to my
initial full refcounting / full locking design. I haven't posted
any patches because I figured it's too low priority and too risky
to be doing right before the merge window.
I agree that reordering is a good idea but not as a fix, and hopefully
without conditional locking in the drivers:
+ if (!reload)
+ devl_lock(devlink);
+ err = mlxsw_driver->ports_init(mlxsw_core);
+ if (!reload)
+ devl_unlock(devlink);
Powered by blists - more mailing lists