On Mon, 2016-09-19 at 11:54 +0200, Johannes Berg wrote:

quoted

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