Re: [PATCH v11 07/20] gpu: nova-core: mm: Add TLB flush support

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

On Fri Apr 17, 2026 at 12:18 AM CEST, Joel Fernandes wrote:
> On 4/16/2026 5:45 PM, Danilo Krummrich wrote:
>> Why do we need the try_access() dance in the first place? I assume this ends up
>> being called from the BarAccess destructor?
>
> BarAccess is different. The try_access() calls here are in tlb.rs and
> pramin.rs for Bar0.

Yes, and we shouldn't need them in the first place; we should have a
&Device<Bound> in all call paths this is called from.

>> If so, I think this is solvable. Gary and me are currently working on
>> higher-ranked types and a chained Devres type.
>
> Hmm, the issue here is we cannot hold revocable guard while sleeping, but
> we have read the bar as a condition in the body of the poll.

No, you should just require a &Device<Bound>; or maybe we can utilize the
mentioned higher-ranked types and DevresChain once we have it. But in any case
you shouldn't need try_access() here.

>> With that, such use-cases should be cleanly solvable without the need for
>> try_access().
>> 
>> Besides that, I can't find where BarAccess is ever constructed.
>
> BarUser::map() constructs it.

I'm well aware, but absolutely nothing calls BarUser::map(). :)

>> It already has a lifetime 'a for &'a Bar1, so I don't see why you can't do the
>> same for Bar0.>
>> But again, I don't see this being constructed and I'm not sure the whole
>> construct works in the first place.
>
> BarAccess uses &'a Bar1 because it's a short-lived scoped object. In long
> lived objects I am trying to avoid this.

Don't get me wrong, if a lifetime is sufficient -- that's great! But I'm
suspicious whether it actually is, since BarAccess is never actually constructed
and hence I can't see how it would be used.