Re: [PATCH net 3/5] ipv6: mcast: fix delay calculation in igmp6_join_group()

[Jakub Kicinski <kuba@kernel.org>]

On Thu, 27 Aug 2026 22:02:27 +0200 Eric Dumazet wrote:
> > So for case 1, is the actual symptom that the randomized delay is lost and
> > the second unsolicited report goes out on the next tick, right behind the
> > first one, rather than a report deferred for weeks or months? The stated
> > symptom implies dropped membership reports and multicast traffic loss, which
> > reads differently for anyone triaging this for stable.
> >
> > Case 2 (a delay inherited from a query with a large maximum response delay
> > exceeding unsolicited_report_interval()) matches the code, and the clamp
> > added here covers both cases either way. Could the first paragraph be
> > reworded to describe the lost randomization and the reuse of the stale
> > expiry instead?  
> 
> OK I can rephrase the changelog to:
> 
> 1. If the timer has already expired (timer.expires <= jiffies), the
>    stale expiry is reused by mod_delayed_work(), causing the second
>    unsolicited report to fire on the very next tick without a
>    randomized delay.
> 
> 2. If the timer was originally armed by a query with a large maximum
>    response delay, delay could exceed unsolicited_report_interval(ma->idev).
> 
> 
> Hopefully, all the AI agents will be happy this time.

Feel free to ignore, I hit send because of the complaint on patch 2.
I may have misunderstood but I read that one as "delete requires 
optmem headroom".