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

[Vitaly Wool]

> 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.

~Vitaly