From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f74.google.com (mail-wm1-f74.google.com [209.85.128.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 A7BCA3806B6 for ; Thu, 29 Jan 2026 10:32:29 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.74 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769682751; cv=none; b=Ree7dwjNJpFM+BUG70Gdv3xHq5KYYvhrEoJ0unr54DpXChENNjeaK5lZmlrN7QEsGu9JmCw9ais991I62U1JphBzOuUbhaYr/jBN3nc4G7hsuEiZg2n/XXI4eMJ1ObrQR60W/IhMZt9pmwML+C5dkBL0u2TKPgf90ojd8WQXjBo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769682751; c=relaxed/simple; bh=F7IyPT0WgjaU9WEpj4UAOEqixQKLgMfrQjAtYcTouSY=; h=Date:In-Reply-To:Mime-Version:References:Message-ID:Subject:From: To:Cc:Content-Type; b=kheOT8CM26DpnXYh2MMWEOtMREEXmcROAuXCpmwwfGH6aLry+mcwRXfQyWRco9TBaO/T3h7mIFwaUiFEx8KDk89gLwnSRQp9sX5eBAaOjyjPq+W8yj2VPBX0UdA7RO0813yJAcTYoHEzLdBow4rzfU+++cmz6un0SfrP+Zg4bR0= 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=N67DnAbB; arc=none smtp.client-ip=209.85.128.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="N67DnAbB" Received: by mail-wm1-f74.google.com with SMTP id 5b1f17b1804b1-47ee1fe7b24so6756565e9.1 for ; Thu, 29 Jan 2026 02:32:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1769682748; x=1770287548; 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=FChTL1041UkS7xZ/nODJqdr44UU77VklPSjBh2zNfj8=; b=N67DnAbBpPxwVYP6T9c81wtSjQ1bQPXoZsISYb1hfggc7Z/c1CFd3UVXlibub/55hc rj91UVNO6ROW7wGyzyUxxVC2715NXpC/2TVCtUNNcjQA+gLuJB694E8OfO5RmUiHOjG3 OcQhQcNUSabUFe91q8GLaWrJK0ukQiWKAwgv63rKTtDaHaJIm1/U1mlIHQBOLZBUpNHZ ZzmB6YKBA6vCH666PRbwyD9ov95bTXSqsFximIHeaHnTZcMY6mbg1Ir3ftQfYqpQZ5Po EONB29biKC484WoisDuP/AvYg6j5TF7uG8d+tiZOffH9rqYgP0mkgUTJNMNuZevA3P50 MgSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769682748; x=1770287548; 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=FChTL1041UkS7xZ/nODJqdr44UU77VklPSjBh2zNfj8=; b=TlfeZD+fA3+PkM07E2f2lqjFUlj1m6K/b7mS2i23sT9IoUlPNkWxXOzjY++sqJrcwL 4aLpPZQ/BIpi0q45qxCB1/szzqFUFHuynCWDLs/tKOEtcgMrbknYYUT0L3nuWbD07WZ8 BJhOaE3lZ+XrdcgxeXY5VIeVAA/ywsphKGJTLYh4KZQX6g5vWzkiwwBnP4Nj1qMPhDeZ 22NV4L6jb5tETZHeWLTCde+CCJOheDhVDFF43E09Gyn90zNsJriXMhL+Pb/scz9VO6Hk Kai2pfz+KidgSqKtdUMzT76pwPK3NmnK+j2fSxF6qGaPyZPDPvNzBplxEcWVD2NzJPuM 3X6w== X-Forwarded-Encrypted: i=1; AJvYcCVo2YiFeE/XVEwVly3cRnTfPomqqLmIA/vgyhOoNjgz2NJ4r7VtSdwt5wVM5AdSskxYI7BOKoMbOA2teKE=@vger.kernel.org X-Gm-Message-State: AOJu0YyfPV0RDzgQUvawSTNzKXz45aWIiWczl20vtIoivJTzNX/TL4Le wkZbYLSUB9EFy9njhewPFdHBkH44eZISTdywsJ6pR6P6Pn4aeW2XnAlf+x7v7yyXCGnVV0wseGA 91mlwf/5dn1pVssRDxQ== X-Received: from wmlm7.prod.google.com ([2002:a7b:ca47:0:b0:47d:47dc:d5d4]) (user=aliceryhl job=prod-delivery.src-stubby-dispatcher) by 2002:a05:600c:4689:b0:477:c71:1fc1 with SMTP id 5b1f17b1804b1-48069c55610mr94558725e9.19.1769682748078; Thu, 29 Jan 2026 02:32:28 -0800 (PST) Date: Thu, 29 Jan 2026 10:32:26 +0000 In-Reply-To: <20260129084119.32994-3-jongan.kim@lge.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 References: <20260129084119.32994-1-jongan.kim@lge.com> <20260129084119.32994-3-jongan.kim@lge.com> Message-ID: Subject: Re: [PATCH v2 2/3] rust: pid: add Pid abstraction and init_pid_ns helper From: Alice Ryhl To: jongan.kim@lge.com Cc: arve@android.com, brauner@kernel.org, cmllamas@google.com, gregkh@linuxfoundation.org, tkjos@android.com, ojeda@kernel.org, boqun.feng@gmail.com, gary@garyguo.net, bjorn3_gh@protonmail.com, lossin@kernel.org, a.hindborg@kernel.org, tmgross@umich.edu, dakr@kernel.org, yury.norov@gmail.com, vitaly.wool@konsulko.se, tamird@gmail.com, viresh.kumar@linaro.org, daniel.almeida@collabora.com, linux-kernel@vger.kernel.org, rust-for-linux@vger.kernel.org, heesu0025.kim@lge.com, ht.hong@lge.com, jungsu.hwang@lge.com, kernel-team@android.com, sanghun.lee@lge.com, seulgi.lee@lge.com, sunghoon.kim@lge.com Content-Type: text/plain; charset="utf-8" On Thu, Jan 29, 2026 at 05:41:18PM +0900, jongan.kim@lge.com wrote: > From: HeeSu Kim > > Add a new Pid abstraction in rust/kernel/pid.rs that wraps the > kernel's struct pid and provides safe Rust interfaces for: > - find_vpid_with_guard: Find a pid by number under RCU protection > - pid_task_with_guard: Get the task associated with a pid under RCU > protection > > Also add init_pid_ns() helper function to pid_namespace.rs to get > a reference to the init PID namespace. > > These abstractions use lifetime-bounded references tied to RCU guards > to ensure memory safety when accessing RCU-protected data structures. > > Signed-off-by: HeeSu Kim This looks really nice, thanks! > +//! Process identifiers (PIDs). > +//! > +//! C header: [`include/linux/pid.h`](srctree/include/linux/pid.h) > + > +use crate::{bindings, ffi::c_int, sync::rcu, task::Task, types::Opaque}; Currently we use this formatting for imports: use crate::{ bindings, ffi::c_int, sync::rcu, task::Task, types::Opaque, // }; > +/// Wraps the kernel's `struct pid`. > +/// > +/// This structure represents the Rust abstraction for a C `struct pid`. > +/// A `Pid` represents a process identifier that can be looked up in different > +/// PID namespaces. > +#[repr(transparent)] > +pub struct Pid { > + inner: Opaque, > +} I would implement Send, Sync, and AlwaysRefCounted for Pid too. > + // SAFETY: `find_vpid` returns a valid pointer under RCU protection, > + // and `Pid` is `#[repr(transparent)]` over `bindings::pid`. > + Some(unsafe { &*(ptr as *const Self) }) It would be nice to extract this cast into a Pid::from_raw(). > + // SAFETY: `pid_task` returns a valid pointer under RCU protection, > + // and `Task` is `#[repr(transparent)]` over `bindings::task_struct`. > + Some(unsafe { &*task_ptr.cast() }) I think it would be nice to add a Task::from_raw() to avoid the cast here. Some(unsafe { Task::from_raw(task_ptr) }) > + pub fn pid_task_with_guard<'a>(&'a self, _rcu_guard: &'a rcu::Guard) -> Option<&'a Task> { > + pub fn find_vpid_with_guard<'a>(nr: i32, _rcu_guard: &'a rcu::Guard) -> Option<&'a Self> { I think we can drop the 'with_guard' suffixes of these. > +/// Returns a reference to the init PID namespace. > +/// > +/// This is the root PID namespace that exists throughout the lifetime of the kernel. > +#[inline] > +pub fn init_pid_ns() -> &'static PidNamespace { > + // SAFETY: `init_pid_ns` is a global static that is valid for the lifetime of the kernel. > + unsafe { PidNamespace::from_ptr(core::ptr::addr_of!(bindings::init_pid_ns)) } Simplifies to: PidNamespace::from_ptr(&raw const bindings::init_pid_ns) Alice