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

[Paolo Abeni <pabeni@redhat.com>]

On 7/10/26 6:15 PM, Kuniyuki Iwashima wrote:
> On Fri, Jul 10, 2026 at 4:08 AM Paolo Abeni <pabeni@redhat.com> wrote:
>> On 7/3/26 2:09 AM, Kuniyuki Iwashima wrote:
>>> @@ -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