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

[Harry Yoo]

On Mon, Oct 19, 2026 at 08:45:55AM +0200, Vitaly Wool wrote:
> 
> 
> > On Oct 18, 2026, at 6:15 PM, Harry Yoo <harry@xxxxxxxxxx> wrote:
> > 
> > On Sun, Oct 18, 2026 at 06:03:15PM +0200, Vitaly Wool wrote:
> >>>> How about we take my patch [1] instead since
> >>>> it isn't prone to this bug and is a nice optimization to the existing
> >>>> mempool_resize() at the same time?
> >>> 
> >>> It is not a good idea to squeeze a bug fix and an optimization
> >>> into one patch.
> >> 
> >> Generally speaking, yes. But that patch had been submitted before the fix
> >> popped up, so there was no sqeezing per se.
> > 
> > I mean the patch you've submitted does two things (wihch is not good).
> > 
> > It should be split into two patches that 1) fixes the bug and 2)
> > optimizes it.
> 
> I don’t think this is a fair statement. I would say that the patch
> I’ve submitted improves mempool_resize() to be rid of unnecessary
> reallocations and data copying, and that (improved) implementation is
> *not* prone to the race found in the previous version of this function.

We backport bugfixes to -stable, but don't want to backport
performance optimizations to -stable in general.

-- 
Cheers,
Harry / Hyeonggon