lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 6 Dec 2022 08:44:16 +0100
From:   Jiri Pirko <jiri@...nulli.us>
To:     Jakub Kicinski <kuba@...nel.org>
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

Tue, Dec 06, 2022 at 02:08:26AM CET, kuba@...nel.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);

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ