Re: [PATCH v1] mempool: fix min_nr exceeding the elements array after concurrent resizes

[Harry Yoo (Meta)]

On Fri, 16 Oct 2026 09:25:10 -0400, Nickolai Zeldovich wrote:
> mempool_resize() shrinks a pool by dropping pool->lock around every
> free_fn() call and, once the pool holds no more than new_min_nr
> elements, stores new_min_nr into pool->min_nr.  new_min_nr was only
> compared against pool->min_nr before the lock was first dropped, so that
> store assumes nothing changed meanwhile.  The kernel-doc allows
> mempool_alloc()/mempool_free() to run while a resize is in progress and
> the grow path also copes with concurrent resizes ("Raced, other resize
> will do our work"), but the shrink path does not: while its lock is
> dropped another resize may shrink the pool below new_min_nr and a third
> one may grow it again to a size between the two, replacing
> pool->elements with an array of exactly that size.  Storing the stale
> new_min_nr afterwards leaves pool->min_nr larger than the elements
> array.
> 
> [...]

Applied to mm/slab.git slab/for-next-fixes, thanks!

[1/1] mempool: fix min_nr exceeding the elements array after concurrent resizes
      commit: 8dde7b06d2d819422c736dad7efb9635b6673cc2

-- 
Cheers,
Harry / Hyeonggon