[BUG] net: ipvlan: down-slave deletion leaks parent allmulti state

[Cheng Yongkang]

Hi all,

ipvlan_change_rx_flags() increments the parent netdevice's allmulti
reference for an ipvlan slave with IFF_ALLMULTI.  Unlike macvlan,
ipvlan_stop() does not release that reference and ipvlan_open() does not
reacquire it as an ownership pair.

If the slave is brought down while IFF_ALLMULTI remains set and is then
deleted, netif_close_many() skips the already-down device, so
ipvlan_stop() is never run.  ipvlan_uninit(), __ipvlan_link_delete() and
ipvlan_port_destroy() also contain no decrement.  The parent therefore
stays in all-multicast mode after every such cycle.

Observed on Linux v7.3, commit
08ab31164c55f20c7a2653de3186ae333470e2c1.  Three
create/allmulti-on/down/delete cycles changed the parent's
IFLA_ALLMULTI count from 0 to 1, 2, and 3.  A later live-slave
allmulti-on/off test changed it 3 -> 4 -> 3, showing that only an
explicit off transition releases one reference.  The leaked reference
survived deletion.

The 2019 review of ipvlan multicast propagation already noted that a
dev_set_allmulti(1/-1) open/stop pair was missing.  Current source still
has the asymmetry.

A fix should pair acquisition/release in open/stop, as macvlan does, or
provide one release path that runs for deletion in both up and down
states.

Candidate BR-014 is the broader deletion-path description of the same
root cause.

The self-checking reproducer and serial log are available on request.

This was found with a multi-agent workflow; the
refcount growth was reproduced in QEMU.

Thanks,
Cheng Yongkang