Re: [PATCH rdma-next 0/9] FRMR pools fixes

[Michael Gur <michaelgur@nvidia.com>]

On 6/10/2026 8:45 PM, Jason Gunthorpe wrote:
> External email: Use caution opening links or attachments
>
>
> On Wed, Jun 10, 2026 at 03:01:36AM +0300, Michael Gur wrote:
>> From: Michael Guralnik <michaelgur@nvidia.com>
>>
>> This series addresses several bugs in FRMR pool handling.
>>
>> Patch 2 fixes incorrect masking of TPH-related bits in the FRMR pool key,
>> which caused stale TPH values to be used when creating handles from an
>> empty pool.
>>
>> Patch 3 fixes set-pinned flow to use the pool key returned from the
>> driver build_key callback instead of the raw key supplied by user.
>>
>> Patch 8 extends the FRMR pools API with a new drop() operation.
>> This allows drivers to update pool state on handle destruction when
>> revocation fails, without incorrectly returning the handle to the pool.
>>
>> The remaining patches fix error path handling, covering cases where memory
>> allocation fails during queue expansion, and where handle creation or
>> destruction operations return errors.
>>
>> Michael Guralnik (9):
>>    RDMA/mlx5: Fix mkey creation error flow rollback
>>    RDMA/mlx5: Fix TPH extraction in FRMR pool key
>>    RDMA/core: Fix skipped usage for driver built FRMR key
>>    RDMA/core: Fix FRMR aging push to queue error flow
>>    RDMA/core: Fix FRMR set pinned push error path
>>    RDMA/core: Avoid NULL dereference on FRMR bad usage
>>    RDMA/core: Fix FRMR handle leak on push failure
>>    RDMA/core: Add ib_frmr_pool_drop for unrecoverable handles
>>    RDMA/mlx5: Drop FRMR pool handle on UMR revoke failure
> These fixes seem OK and Sashiko found two more:
>
> https://sashiko.dev/#/patchset/20260610000145.820592-1-michaelgur%40nvidia.com
>
> Can you send a followup?

Sure, I have a few patches around umr and frmr pools I'm testing and was 
planning to send on the next cycle.
I'll handle these as well in that series.

> I'll pick this up tomorrow

Thanks

>
> Jason