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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <5DADCFE7-B292-4387-A91D-B9CFD062942A@collabora.com>
Date: Tue, 10 Jun 2025 18:04:29 -0300
From: Daniel Almeida <daniel.almeida@...labora.com>
To: Danilo Krummrich <dakr@...nel.org>
Cc: Miguel Ojeda <ojeda@...nel.org>,
 Alex Gaynor <alex.gaynor@...il.com>,
 Boqun Feng <boqun.feng@...il.com>,
 Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Benno Lossin <benno.lossin@...ton.me>,
 Andreas Hindborg <a.hindborg@...nel.org>,
 Alice Ryhl <aliceryhl@...gle.com>,
 Trevor Gross <tmgross@...ch.edu>,
 Sumit Semwal <sumit.semwal@...aro.org>,
 Christian König <christian.koenig@....com>,
 Boris Brezillon <boris.brezillon@...labora.com>,
 Alyssa Rosenzweig <alyssa@...enzweig.io>,
 Lyude Paul <lyude@...hat.com>,
 Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
 Maxime Ripard <mripard@...nel.org>,
 Thomas Zimmermann <tzimmermann@...e.de>,
 David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>,
 linux-kernel@...r.kernel.org,
 rust-for-linux@...r.kernel.org,
 dri-devel@...ts.freedesktop.org,
 Asahi Lina <lina@...hilina.net>
Subject: Re: [PATCH v2 2/2] rust: drm: Add GPUVM abstraction

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