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

[Harry Yoo]

On Thu, Oct 29, 2026 at 08:59:01PM +0000, Harry Yoo (Meta) wrote:
> 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

For the record, I rerouted this from slab/for-next-fixes to
slab/for-next as it's not targeting -stable.

mempool: mempool: fix min_nr exceeding the elements array after concurrent resizes
commit: ce6518e61e3b4bf4f97f7ac6204049b9eba7eb75

-- 
Cheers,
Harry / Hyeonggon