Re: [PATCH v2 net-next 13/14] ipvlan: Protect ipvl_port.ipvlans with mutex.

On 7/10/26 6:15 PM, Kuniyuki Iwashima wrote:

On Fri, Jul 10, 2026 at 4:08 AM Paolo Abeni [off-list ref] wrote:

quoted

On 7/3/26 2:09 AM, Kuniyuki Iwashima wrote:

quoted

@@ -800,9 +831,15 @@ static int ipvlan_device_event(struct notifier_block *unused,
              if (dev->reg_state != NETREG_UNREGISTERING)
                      break;

-             list_for_each_entry_safe(ipvlan, next, &port->ipvlans, pnode)
-                     ipvlan->dev->rtnl_link_ops->dellink(ipvlan->dev,
-                                                         &lst_kill);
+             list_for_each_entry_safe(ipvlan, next, &port->ipvlans, pnode) {
+#if IS_ENABLED(CONFIG_IPVTAP)
+                     if (ipvlan->dev->rtnl_link_ops != &ipvlan_link_ops)
+                             __ipvtap_dellink_ptr(ipvlan->dev, &lst_kill);
+                     else
+#endif
+                             __ipvlan_link_delete(ipvlan->dev, &lst_kill);

I'm not sure if it's worthy a repost, but what about adding a
link_delete_unlocked() cb to `struct ipvl_dev *`? IMHO should make this
code more straight forward.

Since port is allocated in ndo_init(), ipvtap needs to wrap it
and overwrite port->ops everytime for one time (or at ->newlink),
but I don't have strong opinion here.

It would be nicer if I could follow up since this series gets 5-days
penalty on Suie due to too many Sashiko false-positive, get_net(),
and a build warning due to xchg() for veth, and we will likely lose
context next week :)

FTR, I'm not strictly following Suie order - it's more a mix of Suie,
FIFO and common sense. What impact most in series processing is the
sheer amount of patches in PW vs avail time.

/P