Re: [PATCH 1/2] gpu: nova-core: gsp: retain the GSP-RM log buffers after unbind

On Wed Aug 12, 2026 at 1:06 PM BST, Vladislav Zaharov wrote:
> [email protected] wrote:
>> Does this code need a memory barrier (such as dma_rmb()) between reading
>> the 'put' pointer and copying the buffer contents?
>
> Not in the path this code is written for. snapshot() is called from the
> drop path of the log buffers, which is only reached after PinnedDrop for
> GspResources has run the GSP unload sequence, so the GSP is no longer
> writing to these buffers and there is nothing to order against.
>
> The one case where that does not hold is a Gsp::boot() that fails by
> timing out: the GSP may then still be alive and appending while the
> buffers are dropped. The copy is best-effort there - it cannot be made
> atomic either way - but reading a non-zero 'put' and then reading
> contents that predate it is indeed the pattern dma_rmb() exists for.
>
> I am happy to add it, but there is no dma_rmb() abstraction in
> rust/kernel at the moment: sync/barrier.rs only provides the smp_*
> family, and smp_rmb() is not a correct substitute, as on arm64 it uses
> the inner shareable domain rather than the outer shareable one that
> dma_rmb() needs.

See
https://lore.kernel.org/rust-for-linux/[email protected]/

The abstraction part is being upstreamed via tip tree, so they're not currently
present in drm-rust.next. It'll be there when the next backmerge happens.

>
> Would you prefer a small prerequisite patch adding dma_rmb() to
> rust/kernel, or is relying on the unload ordering acceptable, with the
> requirement spelled out in a comment on snapshot()?

Sashiko is a patch review bot so you won't get any response by asking it --
although I suppose this message is written by a LLM too.

Best,
Gary