Re: [PATCH net v8 03/15] net: cache snapshot entries for ndo_set_rx_mode_async

[Stanislav Fomichev <sdf.kernel@gmail.com>]

On 04/22, Paolo Abeni wrote:
> On 4/22/26 12:19 AM, Stanislav Fomichev wrote:
> > On 04/21, Paolo Abeni wrote:
> >> On 4/21/26 11:52 AM, Paolo Abeni wrote:
> >>> On 4/16/26 8:57 PM, Stanislav Fomichev wrote:
> >>>> Add a per-device netdev_hw_addr_list cache (rx_mode_addr_cache) that
> >>>> allows __hw_addr_list_snapshot() and __hw_addr_list_reconcile() to
> >>>> reuse previously allocated entries instead of hitting GFP_ATOMIC on
> >>>> every snapshot cycle.
> >>>>
> >>>> snapshot pops entries from the cache when available, falling back to
> >>>> __hw_addr_create(). reconcile splices both snapshot lists back into
> >>>> the cache via __hw_addr_splice(). The cache is flushed in
> >>>> free_netdev().
> >>>>
> >>>> Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
> >>>> (cherry picked from commit ba3ab1832a511f660fdc6231245b14bf610c05bd)
> >>>
> >>> Are you backporting from 7.2 via time machine??? :-P
> >>>
> >>>> @@ -611,8 +633,8 @@ void __hw_addr_list_reconcile(struct netdev_hw_addr_list *real_list,
> >>>>  		}
> >>>>  	}
> >>>>  
> >>>> -	__hw_addr_flush(work);
> >>>> -	__hw_addr_flush(ref);
> >>>> +	__hw_addr_splice(cache, work);
> >>>> +	__hw_addr_splice(cache, ref);
> >>>
> >>> I think here sashiko has a point, with the cache size being unbounded. I
> >>> guess syzkaller or the like will find a way to make it grow too much.
> >>>
> >>> What about hard-limit it to some reasonable value?!?
> >>
> >> There are a few more remarks from sashiko at the driver level, but
> >> AFAICS are all pre-existing issues.
> >>
> >> I think even the above one it's better handled as a follow-up, so I'm
> >> applying the series as-is (I'll just drop the cherry-pick statement above).
> > 
> > I have a follow-up series to add retries here, but not sure it's the
> > right direction. I can send it once net-next opens just to opinions.
> 
> I'm not sure how you are going to use retries with cache access?!?
> Likely some code could clarify.
> 
> I was wondering about a dumb limit for such cache, possibly netns-wide,
> possibly with a paired sysctl.

Ah, you're more concerned about the cache growth. I'm more worried about
the failed allocations and failed sync :-/ Let me look into cache grown,
should be relatively easy to have some test that keeps adding mc
addresses..