On Mon, 2016-09-19 at 11:54 +0200, Johannes Berg wrote: > > > > The stack trace is useless, but my other annotation showed that the > > table's nelems *underflowed* to -1, so now the worker will continue > > to try to grow it forever. > > > > And this *was* actually a case of duplication, afaict, since it was > multiple virtual interfaces on the same device all connecting to the > same AP.
It seems that __rhashtable_remove_fast_one() should return 0 even in the case of err==1 for the "skip all the maintenance due to list deletion"? --- a/include/linux/rhashtable.h +++ b/include/linux/rhashtable.h @@ -1009,7 +1009,7 @@ static inline int __rhashtable_remove_fast_one( err = 0; } - return err; + return err < 0 ? err : 0; } But that in itself doesn't help. johannes
