Re: [PATCH net v3 1/1] net: hsr: limit node table growth

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2026-04-22 11:45:38 [+0200], Felix Maurer wrote:
> > I don't think the node count exceeds 100 in production. So having a
> > counter which is incremented while adding to the list and decremented
> > while removing items from the list would optimize the "worst case". So
> > instead traversing the list with 1000 we would just give up.
> 
> The counter is what I had in mind. I agree that allocating under the
> lock isn't what we want.
> 
> I'd argue counting through the whole list is the normal case.

yeah but counting here is just a register increment which is cheap. 

> hsr_add_node() is only called after the node table has been searched
> already (without the lock). Here we go through the whole list again
> under the lock to prevent TOCTOU-type situations.
> 
> I agree that, overall, it would be optimizing the worst case, but I
> think it may be worth it to prevent the memory allocations and walking
> the whole list. But I'd go along with the (current) on-the-fly counting
> as well.

Yeah. But then you have to manage the counter on add and removal just
for this "we have too many nodes" case. And theoretically you would have
to hold the list_lock while checking the counter because nodes might be
added on both sides in the RX path (unless you check early lockless &
optimistic and then again before adding under the lock).

So overall this looks simpler.

> Thanks,
>    Felix

Sebastian