netdev - Re: [PATCH net-next v1] devlink: Notify eswitch mode changes to devlink monitor

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fiiqvm3to3rq6yzdvj2uybfqtolrlep63ttjtpa2p7x2p2y6xb@3wh3ya5ujeud>
Date: Sat, 22 Nov 2025 10:14:35 +0100
From: Jiri Pirko <jiri@...nulli.us>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Parav Pandit <parav@...dia.com>, Jiri Pirko <jiri@...dia.com>, 
	netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com, 
	horms@...nel.org
Subject: Re: [PATCH net-next v1] devlink: Notify eswitch mode changes to
 devlink monitor

Fri, Nov 21, 2025 at 03:48:13PM +0100, kuba@...nel.org wrote:
>On Fri, 21 Nov 2025 09:35:24 +0100 Jiri Pirko wrote:
>> Thu, Nov 20, 2025 at 03:52:23PM +0100, kuba@...nel.org wrote:
>> >On Thu, 20 Nov 2025 13:09:35 +0100 Jiri Pirko wrote:  
>> >> Thu, Nov 20, 2025 at 02:56:28AM +0100, kuba@...nel.org wrote:  
>> >> 
>> >> Nope, I reviewed internally, that's why the tag was taken.
>> >>   
>> >> Well, For the rest of the notifications, we have NEW/DEL commands.
>> >> However in this case, as "eswitch" is somehow a subobject, there is no
>> >> NEW/DEL value defined. I'm fine with using GET for notifications for it.
>> >> I'm also okay with adding new ID, up to you.  
>> >
>> >Let's add a DEVLINK_CMD_ESWITCH_NTF. Having a separate ID makes it
>> >easier / possible to use the same socket for requests and notifications.  
>> 
>> Well, you still can use the same socket with just ESWITCH_GET. Request
>> messages are going from userspace, notifications from kernel, there is
>> no mixup.
>
>AFAICT DEVLINK_CMD_ESWITCH_GET is already used from kernel.

You are right.


>We could technically use the seq to differentiate but that's not very
>generic.
>
>> For the sake of consistency, shouldn't the name be ESWITCH_NEW?
>
>No preference on the naming, we can go with _NEW, tho, as I think Parav
>is alluding to, we don't send _NEW when device is created (which would
>be the natural fit for _NEW). Perhaps we should?

devlink_notify(devlink, DEVLINK_CMD_NEW); - is this what you mean by
"when device is created"?

If you mean DEVLINK_CMD_ESWITCH_NEW, then I believe we should send it
both when
1) device is registered, right after we send devlink_notify(devlink, DEVLINK_CMD_NEW);
   in devlink_notify_register()
2) when eswitch config is changed in devlink_nl_eswitch_set_doit()

And for the sake of completeness, we should also send
DEVLINK_CMD_ESWITCH_DEL from devlink_notify_unregister().