From nobody Mon Jun 8 06:36:16 2026 Received: from mail-dy1-f202.google.com (mail-dy1-f202.google.com [74.125.82.202]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id C6F7C2FF170 for ; Fri, 5 Jun 2026 22:25:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.82.202 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780698324; cv=none; b=eWdexza8A91fwaX2/f9nalv1d98h/nlCBGDvv18+IdMSCzW9p7mnqRnzAzmf7gbTu8m1CO0/XY931oPLbi0QqXUGMHW+zztgevOIjT6m3xUQlqvF+M2Fyo0VRKrbqWfuKKEbATMRSdhJMJjEiqWmBWMDnIKZ47KZ84ZjvwHf0cU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780698324; c=relaxed/simple; bh=juvCzx+9b+PGWwUmEGsN7DzOR8HGiGuIxADYptuBz70=; h=Date:Mime-Version:Message-ID:Subject:From:To:Cc:Content-Type; b=bTvmnIpreRAavKDeTVDN2BJrpRDIwqIvr7lOp2MnEts8HOqxwCPGJO0ttxOcbUfRTU64Sbx9YT8L4Sv8z/8YcOVVuge5qLvMisCqsY1D6KSzjOdh0ZrUZ9tikKE115JlYv4KvywkCpQkPnsyEO38qpnOAlOAJknpJRwGElSbRHA= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--samitolvanen.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=dknYRUvA; arc=none smtp.client-ip=74.125.82.202 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=flex--samitolvanen.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="dknYRUvA" Received: by mail-dy1-f202.google.com with SMTP id 5a478bee46e88-30762d67a64so3515237eec.0 for ; Fri, 05 Jun 2026 15:25:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1780698322; x=1781303122; darn=vger.kernel.org; h=cc:to:from:subject:message-id:mime-version:date:from:to:cc:subject :date:message-id:reply-to; bh=hDhseaqiPSLPqHYwXpS4zasRBSNprmSrggrhgGRfur0=; b=dknYRUvAmiokmwYug8IpxC8V2sNme75dZnmTtBElC9djIJc2wIGsag/lIiE76jw37E Nt5aQXMSrh7GBZyP9vh7Ou25+UZ893pZeymJT1xg32zu7HN8QHdMat6LZviHwfGrcM8j YwehkAnTPU29grgm2qYRWYiZ5p+AGuFFHW8GzMpwBPtbI6Cs0VF8iGtT1RSwwGxbpjQp OAe8GlfibaLyDP8rP6ZBLw0K7pZjOVYXPc6/XjbJTjdHQw21eFATMaIQIkdTdueKP+NY VBiGg7YedkKVzaI9BYZ9j7W1VYIYo8yLsX7f96owbQBXGdCN1nb2wMyNf5sYalR78iZr WI3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1780698322; x=1781303122; h=cc:to:from:subject:message-id:mime-version:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=hDhseaqiPSLPqHYwXpS4zasRBSNprmSrggrhgGRfur0=; b=hnC6Fl3ConqDezQesz7bivlLkqCanTg5SHEETGzNvedGrxXp1qt4RCNHw+X+KodbxT K1qyzHZKJAKE0mPsoJwzypkHPJU8XxonR4KsF1vhTObx6M1bQNrldP5iRXfKYXfvk2cw 1zxqqmlwPO8efc6PhyNZqh3wV0WBQJ0ZUHD7kJAW7vLKlzKteUOhPHEGQO2Ef38z/zrp NnkB4N5Dl9IvidfsAwFgZiAYTsNukthepFCBv3J/f4MWlIylWQYnHy6SNAyLf1dLuGyH 73bsYsGdHD5emJiM5V5A0xMh+tdvt8UxyaJUErGX8FfmtyMtF3vMfpUQhzxtM+vCABvn b1LQ== X-Forwarded-Encrypted: i=1; AFNElJ+RK1fuCWKfwLjNVLtHo+iAa8oi20qq+M6WA9mNHUAs2ykJ2kUilvVkdBLLx5rT3z0PdlqeRue1mD4EvBc=@vger.kernel.org X-Gm-Message-State: AOJu0YyCfphoM/Q5QQVObnMW2X+FlEVaXVIe0eC201YGBkiAHG6C4ANu 8dvCtvHQdkZQ7diBUT4j4aDB1hZd6pGhSza57ffWR2ZD6PpR9RDhOoODu6RF7djkfTzWtJg89Ki 5HmCjM9yZoAwrmX1kiHNGPzXRbrKHTA== X-Received: from dld33.prod.google.com ([2002:a05:7022:321:b0:138:50e:5095]) (user=samitolvanen job=prod-delivery.src-stubby-dispatcher) by 2002:a05:7022:204:b0:137:edc4:a5e6 with SMTP id a92af1059eb24-138066fa2ddmr2765989c88.29.1780698321542; Fri, 05 Jun 2026 15:25:21 -0700 (PDT) Date: Fri, 5 Jun 2026 22:25:16 +0000 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 X-Developer-Key: i=samitolvanen@google.com; a=openpgp; fpr=35CCFB63B283D6D3AEB783944CB5F6848BBC56EE X-Developer-Signature: v=1; a=openpgp-sha256; l=2979; i=samitolvanen@google.com; h=from:subject; bh=juvCzx+9b+PGWwUmEGsN7DzOR8HGiGuIxADYptuBz70=; b=owGbwMvMwCUWxa662nLh8irG02pJDFnKPmecKlLkM7SP6/yoqTW79djb0/zolau+05P0V4Uc+ /TmxpX3HaUsDGJcDLJiiiwtX1dv3f3dKfXV5yIJmDmsTCBDGLg4BWAiX2MYGU4JWCy8o7mz7Ow7 +/wN4ZNnC/RsLTtzQUNP8u+jT4WJsq8ZGa7MKfR7PdPj7MJfcubTJX93rmrZM21b3+QbmsduPVq X1s4FAA== X-Mailer: git-send-email 2.54.0.1032.g2f8565e1d1-goog Message-ID: <20260605222516.3138740-2-samitolvanen@google.com> Subject: [PATCH] rust: drm: gpuvm: implement Send and Sync for GpuVaAlloc and GpuVmBo From: Sami Tolvanen To: Danilo Krummrich , Matthew Brost , "=?UTF-8?q?Thomas=20Hellstr=C3=B6m?=" , Alice Ryhl , David Airlie , Simona Vetter , Miguel Ojeda , Boqun Feng , Gary Guo , "=?UTF-8?q?Bj=C3=B6rn=20Roy=20Baron?=" , Benno Lossin , Andreas Hindborg , Trevor Gross Cc: Sami Tolvanen , dri-devel@lists.freedesktop.org, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" A GpuVaAlloc holds only uninitialised memory with no live VaData and hands out no reference to its contents, so it is Send and Sync unconditionally. A GpuVmBo is refcounted atomically and its deferred put is sound from any thread. Implement the markers in the abstraction so drivers can move these objects between threads without an unsafe impl of their own. Send for GpuVmBo requires VmBoData: Send because the data is dropped during deferred cleanup, on whichever thread drains the queue. Sync requires both VmBoData: Sync and Object: Sync because the &self data() and obj() accessors hand out &VmBoData and &Object. Signed-off-by: Sami Tolvanen --- rust/kernel/drm/gpuvm/va.rs | 8 ++++++++ rust/kernel/drm/gpuvm/vm_bo.rs | 15 +++++++++++++++ 2 files changed, 23 insertions(+) diff --git a/rust/kernel/drm/gpuvm/va.rs b/rust/kernel/drm/gpuvm/va.rs index 0b09fe44ab39..dcb2dec4fbdf 100644 --- a/rust/kernel/drm/gpuvm/va.rs +++ b/rust/kernel/drm/gpuvm/va.rs @@ -104,6 +104,14 @@ pub fn vm_bo(&self) -> &GpuVmBo { /// The memory is zeroed. pub struct GpuVaAlloc(KBox>>); =20 +// SAFETY: A [`GpuVaAlloc`] is an owned, uninitialised allocation with no = live `T::VaData` and no +// thread-bound state. +unsafe impl Send for GpuVaAlloc {} + +// SAFETY: A [`GpuVaAlloc`] has no `&self` method that reaches its content= s, so a shared +// `&GpuVaAlloc` cannot access the allocation. +unsafe impl Sync for GpuVaAlloc {} + impl GpuVaAlloc { /// Pre-allocate a [`GpuVa`] object. pub fn new(flags: AllocFlags) -> Result, AllocError> { diff --git a/rust/kernel/drm/gpuvm/vm_bo.rs b/rust/kernel/drm/gpuvm/vm_bo.rs index c064ac63897b..016b10e3305b 100644 --- a/rust/kernel/drm/gpuvm/vm_bo.rs +++ b/rust/kernel/drm/gpuvm/vm_bo.rs @@ -19,6 +19,21 @@ pub struct GpuVmBo { data: T::VmBoData, } =20 +// SAFETY: The refcount in `self.inner` is atomic, so `dec_ref`'s deferred= put is sound from any +// thread. `data` is dropped later by `drm_gpuvm_bo_deferred_cleanup`, on = whichever thread drains +// the queue, hence the `T::VmBoData: Send` bound. +unsafe impl Send for GpuVmBo where T::VmBoData: Send {} + +// SAFETY: The fields of `inner` read by shared-reference methods are immu= table after construction. +// [`Self::data`] hands out `&T::VmBoData` and [`Self::obj`] hands out `&T= ::Object`, so sharing +// `&Self` across threads requires both to be `Sync`. +unsafe impl Sync for GpuVmBo +where + T::VmBoData: Sync, + T::Object: Sync, +{ +} + // SAFETY: By type invariants, the allocation is managed by the refcount i= n `self.inner`. unsafe impl AlwaysRefCounted for GpuVmBo { fn inc_ref(&self) { base-commit: fea3a2dd7d3fc1936211ced5f84420e610435730 --=20 2.54.0.1032.g2f8565e1d1-goog