Re: [PATCH v2 2/2] rust: drm: Add GPUVM abstraction

[Daniel Almeida <daniel.almeida@collabora.com>]

Hi Danilo,

> The lock might be held already by the driver or by TTM when things are called
> from TTM callbacks.
> 
> This is why GPUVM never takes locks by itself, but asserts that the correct lock
> is held.
> 
> I think we really want to get proof by the driver by providing lock guard
> references.

Can’t we add a lock to our Rust GpuVmBo type?

This is already supported by the C code, since it asks driver to either provide
a custom lock _or_ use the bo's resv. So what I am suggesting here is the
former, except that said lock would be transparently managed by our Rust GPUVM
abstraction.

By using our own lock, we forbid drivers from introducing races.

Another option is to also require a(nother) Guard when mutating the BO's VA
list, but I find this a bit cumbersome for a couple of reasons:

a) It's proving a bit difficult to provide said Guard for the interval tree
itself,

b) This will appear in all functions where the lock should be taken, which
pollutes the API quite a bit.

c) Having "either a custom lock or the resv lock" sounds a bit confusing.
Handling this transparently in Rust makes the API easier to use (and harder to
misuse)

— Daniel