On Mon, 2016-09-19 at 12:02 +0200, Johannes Berg wrote: > 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; > } >
No, that's obviously bogus and already handled - wrong case anyway. Sorry. johannes
