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

[Harry Yoo]

On Tue, Oct 20, 2026 at 12:50:38PM +0200, Vitaly Wool wrote:
> 
> 
> > On Oct 20, 2026, at 10:27 AM, Vlastimil Babka (SUSE) <vbabka@xxxxxxxxxx> wrote:
> > 
> > On 10/19/26 08:45, 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.
> > 
> > But it makes the code more complex:
> > 
> > 2 files changed, 28 insertions(+), 16 deletions(-)
> > 
> > without an in-tree use case.
> 
> It does help bulk-zoned, e. g. on a device-mapper table change that grows the
> pool.

Please provide data, rather than a theory without data.

-- 
Cheers,
Harry / Hyeonggon