Re: [patch net-next 0/8] devlink: make sure devlink port registers/unregisters only for registered instance

[Jiri Pirko <jiri@resnulli.us>]

Tue, Dec 06, 2022 at 02:08:26AM CET, kuba@kernel.org wrote:
>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'm missing how what you describe is relevant to this patchset and to
the issue it is trying to solve :/ 


>
>I agree that reordering is a good idea but not as a fix, and hopefully

I don't see other way to fix the netdev/devlink events ordering problem
I described above. Do you?



>without conditional locking in the drivers:
>
>+		if (!reload)
>+			devl_lock(devlink);
>+		err = mlxsw_driver->ports_init(mlxsw_core);
>+		if (!reload)
>+			devl_unlock(devlink);