Re: [RFC] RDMA/irdma: Add support for revocable dmabuf import

[Jason Gunthorpe <jgg@ziepe.ca>]

On Tue, Feb 17, 2026 at 06:08:54PM -0500, Jacob Moroni wrote:
> Hi,
> 
> Thanks for taking a look.
> 
> > Really need to explain this better, I forget how iwarp works - but you
> > can't release the rkey/stag in a way that something else can get it
> > reallocated.
> 
> I think the HW command names are a little confusing, but for irdma, the key
> allocation is actually handled by the driver. The key can't be reused until
> the region is fully deregistered (which calls irdma_free_stag), so a new
> registration can't grab the same key even if the dmabuf revocation occurs.

Hmm, maybe that is OK then. Please explain it though more clearly like
this paragraph
 
> > Finally, we don't actually support revocable mappings at the core code
> > level. We either have fully pinned or fully movable, so this is not
> > right to just change to ib_umem_dmabuf_get(), that assumes the HW is
> > fault capable.
> 
> Ack. It sounds like what I really want is more like ib_umem_dmabuf_get_pinned
> but with a functional invalidate_mappings method?

Yes, method provided by the driver.

> > Probably what you want to do is add a revoke callback to the pinned
> > importer?
>
> That does seem ideal.

Probably, but  I  mean some argument to the
ib_umem_dmabuf_get_pinned(), not a whole new op for MRs..

> Re-registering it as a 0 length region (will check
> the spec) seems like the easiest way to achieve it. Using a special PD
> for quarantine purposes should also work, but it would add a little more
> state and an object to manage (could we keep it in struct ib_device?).

Yes these are good options, but if they rkey is preserved it is not
strictly necessary to do these things. Pedentically the user should be
able to re-reg that mkey and revive it, but nobody does that and you
don't have to try to implement it.

> Should I create a new kernel device method for this? If so, then I wonder if
> it makes sense to expose it as a generic "invalidate_mr" method and let
> the drivers choose now to actually implement it (many can probably just
> forward the call to their internal rereg_mr logic).

I have on and off thought about doing something like that with rereg
mr as it would be more general, but I think for now just extending the
ib_umem_dmabuf_get_pinned() is reasonable, and avoids the races.

Keep in mind umems are used for more than just MRs, so a global op
gets a bit tricky.

Jason