Re: [PATCH v10 1/2] rust: Add dma_fence abstractions

["Danilo Krummrich" <dakr@kernel.org>]

On Fri Sep 4, 2026 at 8:53 PM CEST, Philipp Stanner wrote:
> On Fri, 2026-09-04 at 17:32 +0200, Danilo Krummrich wrote:
>> On Wed Aug 12, 2026 at 9:22 AM CEST, Philipp Stanner wrote:
>> > Add abstractions for dma_fence in Rust.
>> 
>> I was about to pick this up, but ended up with too many things to tweak.
>
> :(
>
>> 
>>   * Fix checkpatch.pl warnings,
>
> I get two, one of them being obsolete

I think the other one was a spelling mistake, do you run --codespell?

> WARNING: added, moved or deleted file(s), does MAINTAINERS need updating?
> #114: 
> new file mode 100644
>
> WARNING: line length of 101 exceeds 100 columns
> #158: FILE: rust/helpers/dma_fence.c:40:
> +__rust_helper void rust_helper_dma_fence_unlock_irqrestore(struct dma_fence *f, unsigned long *flags)
>
>
>> 
>>   * use Opaque::zeroed() instead of __GFP_ZERO,
>
> That's literally what I had originally, but Alice objected and wanted
> GFP_ZERO, AFAIR because it's more efficient.

I don't think you can say this in general, it depends e.g. on the size of
T::FenceDataType, etc.

But struct dma_fence is pretty small, I doubt one can even measure the overhead.
Besides that, fence context creation is a cold path with many *much* more
expensive operations.

If we'd really care about that, you could also do neither as __dma_fence_init()
should write all fields anyway.

> Maybe you two want to get to an agreement on what's better.

Nah, it doesn't really matter, anything is fine with me.

>>   * use kernel vertical import style.
>> Here's the diff I suggest for a v11:
>
> Thx, I'll take it into account.