Le 25/09/2026 à 09:58, Nicolas Dichtel a écrit :
> Le 24/09/2026 à 03:15, Yuyang Huang a écrit :
>> A multi-part RTM_GETMULTICAST dump of dev->mc resumes by position, so
>> entries added or removed between two dump rounds can be skipped or
>> repeated. The IPv4 and IPv6 dumps report that with NLM_F_DUMP_INTR by
>> stamping cb->seq from a per netns generation counter combined with
>> dev_base_seq, see inet_base_seq().
>>
>> Add the equivalent for the device multicast lists: a per netns counter
>> bumped whenever an entry is added to or removed from any dev->mc. The
>> list helpers do not know which device a list belongs to, so give
>> netdev_hw_addr_list an owner set for dev->mc only and bump the counter
>> of dev_net(owner) where entries are created and freed. That covers the
>> dev_mc_* helpers, both lists of a sync, the hardware sync helpers
>> drivers call from their rx mode callbacks or their own workers and the
>> reconciliation after an asynchronous rx mode update, while snapshot
>> and other lists have no owner and are not tracked. It is atomic since
>> the writers only hold the address lock of their own device.
>
> For IPv4 and IPv6, the generation counter was initially used to invalidate
> some
> caches; that's why it is global. Here, the goal is only to check the
> consistency
> of the netlink dump. I wonder if maintaining a counter per list would not be
> more straightforward.
Forget, it doesn't fit in the netlink consistency framework (:
