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
