On 04/21/15 at 10:10pm, David Miller wrote: > From: Herbert Xu <herb...@gondor.apana.org.au> > Date: Wed, 22 Apr 2015 08:36:34 +0800 > > > On Tue, Apr 21, 2015 at 02:55:34PM +0200, Thomas Graf wrote: > >> When rhashtable_insert_rehash() fails with ENOMEM, this indicates that > >> we can't allocate the necessary memory in the current context but the > >> limits as set by the user would still allow to grow. > >> > >> Thus attempt an async resize in the background where we can allocate > >> using GFP_KERNEL which is more likely to succeed. The insertion itself > >> will still fail to indicate pressure. > >> > >> This fixes a bug where the table would never continue growing once the > >> utilization is above 100%. > >> > >> Fixes: ccd57b1bd324 ("rhashtable: Add immediate rehash during insertion") > >> Signed-off-by: Thomas Graf <tg...@suug.ch> > > > > Good catch. But I think this call should happen in > > rhashtable_insert_rehash since it's on the slow-path. > > Ok, then I expect a respin of this series.
Agreed, respinning. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html