From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ej1-f74.google.com (mail-ej1-f74.google.com [209.85.218.74]) (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 3A75938331D for ; Fri, 3 Jul 2026 06:44:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.218.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783061048; cv=none; b=i5b2ljkkbzMQjehuvQb8QtxKFoN9wu2taaeejMZD+M/Dpv3DDq8HmCcdPftnOmXf4jlbRhygfgcftI+a3apsAMfMV475aRZtLwYDCXsUKOtU8R0Ys3Kt+TvZJLJ3xe0G93oiji+rtOWWRlPceb9LtV9qwMJz1A+ezmBl1Kmlrrg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783061048; c=relaxed/simple; bh=Pf5q80ck+5U2ixrJWHV1AI8ArmR0ZtcwQp0edbeGpww=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=qhE1odeEsQLL+ghFt+pcRsB3e3Ltiszh73by9C0qL59nfO94OT9XBAphkokuBbgoDaj+OPfFmTu/Q7oL6NSzb4ioBBk4hdi+bV4YsuDDtedlZbWpkDK1bYi7XgJ08/B2lJ1wSbnAAmYl8aWipNnebffPT6y3W7YBwLPNIZbf5PQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=flex--aliceryhl.bounces.google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=W+FmElDN; arc=none smtp.client-ip=209.85.218.74 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--aliceryhl.bounces.google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="W+FmElDN" Received: by mail-ej1-f74.google.com with SMTP id a640c23a62f3a-c126bfee5a0so16656066b.3 for ; Thu, 02 Jul 2026 23:44:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1783061044; x=1783665844; darn=vger.kernel.org; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:from:to:cc:subject:date:message-id:reply-to; bh=7jmn19R8R/PMFgOwF2vvch2Q5bX9NRBwJ66kDptBPuo=; b=W+FmElDN4VaaCXPTn0XY0hv5l51N0X3byqc05enxGVDIPNLvdQ2UQn+TswXto1cl1V 5SAeNRmYNu5+ZFtWbLh/lnfc/KtidHCBQil+T8Cacb+JrYJjROfhV64Bvc2d8D9QVXZ2 f/La56Kr1MAU72ogAS3QxgLN7li2xd0jJ0IZnV0EY+m2iCnrWdsWxT+ykEP0kJjbEh9i 6RZZ1RqpA+b+m6pR0T24QwgnogHInabzSh7UUmidbdGE+JPPhjb9Mf7006FYzyqRM+3G 698y8/CysbtS0Jnr6orXpNMX1BZ8ky8XRJQkOEacss8f+fGMT9J8StYBvZtla8g9RtsW nqvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783061044; x=1783665844; h=cc:to:from:subject:message-id:references:mime-version:in-reply-to :date:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=7jmn19R8R/PMFgOwF2vvch2Q5bX9NRBwJ66kDptBPuo=; b=tJ3rpjyTi9+jgWzz/VEKDWXL5IFoom4CtMuzQH3nfeOvomYFdX/AsDwGoIbMBE+TBc BzGcP8SMAprY39Sk7o8cAuCW9KtyIB4CfoqRPl//Dz2sOsE564zs70rPcOokypq1bQho tiJKs+2pPpE2B5+wt8nilP7qJ9d5RlWObC746HHn+wD/Ti8BwBnlX77VoyIdSMPh7leX f0TlFZtmRQLgbf5ztMyaTKtLGZfNb8nyjEHA4fM+Bb46G5iYZm48HWgUCaRTe2jsLgVr gMaY9lg8zJ2vqag9fjMUW/BOGxrx9wKWdw6/jrZqEQShteOsw31uX3pe6tHdoGvDID9F KsyQ== X-Forwarded-Encrypted: i=1; AHgh+RowbVkqZBMuq6H4DadrRHsnAYxbXDN8vbLdKYGB3MMEN1vT++7Xd10zV7UTXKoyhL3vtzEwiNz31cqjUTU=@vger.kernel.org X-Gm-Message-State: AOJu0Yz8s4Kcpik+gtbHUMInSVFrv8FffOKD3h1E66hKtZHvu08e4bu1 BFimmFAm34kUa+UVAxtR9SfMd++JLHLFseYT9kV5smz6KzvbXy2Ss2XZbY3ROt2YigIPnXla44L iuJtP6Im4TTVEJWaQqQ== X-Received: from ejj11-n1.prod.google.com ([2002:a17:906:a34b:10b0:c12:d541:2b1]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a17:907:970e:b0:c10:256:3d6a with SMTP id a640c23a62f3a-c12aa1b0166mr449505466b.31.1783061043110; Thu, 02 Jul 2026 23:44:03 -0700 (PDT) Date: Fri, 3 Jul 2026 06:44:01 +0000 In-Reply-To: <20260702-pgtable_lt_v1-v1-1-18d9c9812a1a@collabora.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260702-pgtable_lt_v1-v1-1-18d9c9812a1a@collabora.com> Message-ID: Subject: Re: [PATCH] rust: iommu: add device lifetime to IoPageTable From: Alice Ryhl To: Deborah Brouwer Cc: "Joerg Roedel (AMD)" , Will Deacon , Robin Murphy , Miguel Ojeda , Boqun Feng , Gary Guo , "=?utf-8?B?QmrDtnJu?= Roy Baron" , Benno Lossin , Andreas Hindborg , Trevor Gross , Danilo Krummrich , iommu@lists.linux.dev, rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org, samitolvanen@google.com, boris.brezillon@collabora.com, laura.nao@collabora.com, daniel.almeida@collabora.com Content-Type: text/plain; charset="utf-8" On Thu, Jul 02, 2026 at 04:47:39PM -0700, Deborah Brouwer wrote: > Currently, using a raw IoPageTable is unsafe because the returned > IoPageTable is not tied to the device driver binding lifetime. > > Since device drivers now receive a lifetime parameter <'bound> > representing the interval during which a device driver is bound to its bus > device, add this lifetime parameter to IoPageTable. This ensures that > the returned IoPageTable cannot outlive the bus device binding. > > Also temporarily remove the option to create a page table as a device > resource since currently Devres is not compatible with resources that have > a lifetime parameter. This option can be restored once the lifetime-aware > wrapper for devres is available. > > Suggested-by: Boris Brezillon > Signed-off-by: Deborah Brouwer > --- > rust/kernel/iommu/pgtable.rs | 32 ++++++++++---------------------- > 1 file changed, 10 insertions(+), 22 deletions(-) > > diff --git a/rust/kernel/iommu/pgtable.rs b/rust/kernel/iommu/pgtable.rs > index c88e38fd938a..d4a16283b5a7 100644 > --- a/rust/kernel/iommu/pgtable.rs > +++ b/rust/kernel/iommu/pgtable.rs > @@ -16,7 +16,6 @@ > Bound, > Device, // > }, > - devres::Devres, > error::to_result, > io::PhysAddr, > prelude::*, // > @@ -59,15 +58,16 @@ pub struct Config { > /// # Invariants > /// > /// The pointer references a valid io page table. > -pub struct IoPageTable { > +pub struct IoPageTable<'bound, F: IoPageTableFmt> { > ptr: NonNull, > + _dev: PhantomData<&'bound Device>, > _marker: PhantomData, > } > > // SAFETY: `struct io_pgtable_ops` is not restricted to a single thread. > -unsafe impl Send for IoPageTable {} > +unsafe impl Send for IoPageTable<'_, F> {} > // SAFETY: `struct io_pgtable_ops` may be accessed concurrently. > -unsafe impl Sync for IoPageTable {} > +unsafe impl Sync for IoPageTable<'_, F> {} > > /// The format used by this page table. > pub trait IoPageTableFmt: 'static { > @@ -75,25 +75,12 @@ pub trait IoPageTableFmt: 'static { > const FORMAT: io_pgtable_fmt; > } > > -impl IoPageTable { > - /// Create a new `IoPageTable` as a device resource. > - #[inline] > - pub fn new( > - dev: &Device, > - config: Config, > - ) -> impl PinInit>, Error> + '_ { > - // SAFETY: Devres ensures that the value is dropped during device unbind. > - Devres::new(dev, unsafe { Self::new_raw(dev, config) }) > - } > +impl<'bound, F: IoPageTableFmt> IoPageTable<'bound, F> { > + // TODO: Create a new `IoPageTable` as a device resource when DevresLt is available. > > /// Create a new `IoPageTable`. > - /// > - /// # Safety > - /// > - /// If successful, then the returned `IoPageTable` must be dropped before the device is > - /// unbound. > #[inline] > - pub unsafe fn new_raw(dev: &Device, config: Config) -> Result> { > + pub fn new_raw(dev: &'bound Device, config: Config) -> Result> { The name new_raw() indicates that this is something you only use in rare cases when you are doing weird stuff. But with this change, I no longer think that's the case. I would suggest renaming this method to just `new()`. As for creating a device resoure version with DevresLt, I think that can be the secondary constructor and be called `new_devres()` or similar. Otherwise LGTM. Alice