Re: [PATCH 3/4] rust: Add dma_fence abstractions

[Alice Ryhl <aliceryhl@google.com>]

On Mon, Jun 01, 2026 at 03:30:38PM +0200, Philipp Stanner wrote:
> On Mon, 2026-06-01 at 15:14 +0200, Philipp Stanner wrote:
> > +Cc Boris
> > 
> > On Mon, 2026-06-01 at 14:55 +0200, Alice Ryhl wrote:
> > > On Mon, Jun 1, 2026 at 2:34 PM Philipp Stanner <phasta@mailbox.org> wrote:
> > > > 
> > > > On Mon, 2026-06-01 at 10:20 +0000, Alice Ryhl wrote:
> > > > > For example, let's say I'm using RcuBox<_> here. Yes, the data you get
> > > > > from dereferencing the RcuBox will stay alive for a grace period, but
> > > > > IMO once you run the destructor of the box itself, the *pointer* becomes
> > > > > immediately unusable.
> > > > 
> > > > I don't know why you're stressing the pointer?
> > > > 
> > > > The trick above is simply that drop / dealloc *and* code unloading is
> > > > delayed by a grace period.
> > > 
> > > Sorry let me try to rephrase. I'm not worried about the stuff behind
> > > the pointer. After all, you're using RcuBox to protect that stuff.
> > > What I'm worried about is the pointer itself. You invoked
> > > drop_in_place() on the pointer to the fence context,
> > > 
> > 
> > on the pointer to DriverFenceData, which contains a refcount to the
> > FenceCtx, which might then want to drop.
> > 
> > >  so even though
> > > the fence context may be valid for another grace period, the *pointer*
> > > to the fence context is not. The pointer could have been zeroed by the
> > > destructor.
> > 
> > That particular pointer to the DriverFenceData could have been zeroed.
> > But potential other accessors have already crafted themselves a new
> > pointer to the, by the power of RCU, still valid data.
> > 
> 
> correction:
> it is refcounting that ensures the memory is still valid.
> 
> dma_fence_put() in DriverFence::drop() could earliest free the memory.

Hrm, actually I realized that this is not quite Boqun's RcuFreeSafe.
That trait would require the fence allocation itself to remain valid for
one grace period, but you don't require that.

Alice