On Tue, 15 Sep 2026 06:04:24 +0000 [email protected] wrote: > > + cmd = PSP_CMD_DEV_DEL_NTF; > > + ntf = psp_nl_build_dev_ntf(psd, net, &cmd); > > + if (ntf) > > + genlmsg_multicast_netns(&psp_nl_family, net, ntf, 0, > > + PSP_NLGRP_MGMT, GFP_KERNEL); > > + put_net(net); > > +} > > [Severity: Low] > > This isn't a bug, but should the assoc side be made symmetric with this? > > After this change, losing visibility of a PSP device in a netns produces > PSP_CMD_DEV_DEL_NTF, while gaining visibility for the first time still > produces only a change notification in psp_nl_dev_assoc_doit(): > > list_add_tail(&psp_assoc_dev->dev_list, &psd->assoc_dev_list); > psd->assoc_dev_cnt++; > > put_net(net); > > psp_nl_notify_dev(psd, PSP_CMD_DEV_CHANGE_NTF); > > For a netns where this is the first association, psp_dev_check_access(psd, > net, false) would have returned -ENOENT just before the list_add_tail(), > i.e. the device was not visible there at all, yet the netns is only told > about it with a change notification. > > Documentation/netlink/specs/psp.yaml describes dev-add-ntf as "Notification > about device appearing" and dev-del-ntf as "Notification about device > disappearing", and psp_dev_create()/psp_dev_unregister() use that add/del > pair. A mgmt listener in an associated namespace would then get a change-ntf > for an object it was never told about, followed later by a del-ntf for it. > > Since notification semantics become uAPI once released, would it make sense > to emit PSP_CMD_DEV_ADD_NTF to a namespace which becomes able to see the > device for the first time?
Bunch of extra LoC, and it's fairly common in netlink for events not to differentiate between "new" and "changed".
