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

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

On 10/19/26 08:45, Vitaly Wool wrote:
> 
> 
>> On Oct 18, 2026, at 6:15 PM, Harry Yoo <harry@kernel.org> 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.

> ~Vitaly