From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id B6F6CE77197 for ; Thu, 9 Jan 2025 08:42:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 295DE6B007B; Thu, 9 Jan 2025 03:42:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 245856B0082; Thu, 9 Jan 2025 03:42:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 10D8F6B0083; Thu, 9 Jan 2025 03:42:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id E13B56B007B for ; Thu, 9 Jan 2025 03:42:55 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 3F60D12096B for ; Thu, 9 Jan 2025 08:42:55 +0000 (UTC) X-FDA: 82987273110.26.FDEF3CC Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf13.hostedemail.com (Postfix) with ESMTP id 72AF42000B for ; Thu, 9 Jan 2025 08:42:53 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ICjvHPlq; spf=pass (imf13.hostedemail.com: domain of a.hindborg@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=a.hindborg@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1736412173; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=rSethJSOuEKgGJzHrcqLPlxIc1++xUOJeRb9bZQchyg=; b=57SPvBDNo/lhsn/mxq0d2TCvqVbrNLJmQtcV2V/JlXMLujEwfNU1Mtp/7YI5QiZRej2eKN uTNaETspaZGwY4cuT7iNnSIQD0EXt45iO1Cz2H03kDPWzvivFVVuSXMOscnEuHk+h2tsuG PapvaihR4HjhN89PwX9anWTp61gDC9o= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ICjvHPlq; spf=pass (imf13.hostedemail.com: domain of a.hindborg@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=a.hindborg@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736412173; a=rsa-sha256; cv=none; b=A1hbvhWoJ149BjnGejrxarlDMXIXtWD9X1T9kSKSr5oJusD5JFUACMU/9p6Cf75L9jsrI+ sxGV2JtmLdKRbrfd3sPrAWxagf48x4xHLHnanFEGNWATzkTVcfLlw8NxOU/l6q4FKzvCau iw+q1JysHIrVs++0UlN5aVxekuF4/es= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 0A771A41457; Thu, 9 Jan 2025 08:41:04 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 54F2AC4CED2; Thu, 9 Jan 2025 08:42:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736412172; bh=PhMWVkGP4H8b6b24Flid4Nn/KUJYU0Y+xwXr/mirWBs=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ICjvHPlqK7b7PEe+CtIItBUm670tDTyD022FWKIRM0Gay+yCICMur+VzGs4AO0tiT e615Ub5/Q9bcNkiMydTgIN6rd9NZVm7Ls/izsrsbMbAj0wclqG5YZS1qnSlSFYjeT6 57Kjxn/21kj5mAyzlt7TffsQmJIoqgBJc0LkDC1tr1BVTNvIeE0k3A7ecEoobtqihh zerMCxqtYqKuUYSUno7O/BjuFDDVVD3fgbl77iowL9mrpNWNk7KaiddrtnIJg/kxXS v+yAUtLdulLVJrmVWrATLQ6bLwsabuON+bfQV9+NeXMDJQlxDsqm+NET2EXl2gMvLS HeLWZJtaAGUpg== From: Andreas Hindborg To: "Alice Ryhl" Cc: "Miguel Ojeda" , "Matthew Wilcox" , "Lorenzo Stoakes" , "Vlastimil Babka" , "John Hubbard" , "Liam R. Howlett" , "Andrew Morton" , "Greg Kroah-Hartman" , "Arnd Bergmann" , "Christian Brauner" , "Jann Horn" , "Suren Baghdasaryan" , "Alex Gaynor" , "Boqun Feng" , "Gary Guo" , =?utf-8?Q?Bj=C3=B6rn?= Roy Baron , "Benno Lossin" , "Trevor Gross" , , , Subject: Re: [PATCH v11 8/8] task: rust: rework how current is accessed In-Reply-To: (Alice Ryhl's message of "Wed, 08 Jan 2025 13:32:28 +0100") References: <20241211-vma-v11-0-466640428fc3@google.com> <20241211-vma-v11-8-466640428fc3@google.com> <87frmnadmk.fsf@kernel.org> <5qXA_x0NK0TzOkDwdQ8RYbk3SboUQiD0qflQhsoPRyhFxpD7fZHC7uVjI7RQBvvHPVEO1zlMRBq3F8BBImHrYQ==@protonmail.internalid> User-Agent: mu4e 1.12.7; emacs 29.4 Date: Thu, 09 Jan 2025 09:42:38 +0100 Message-ID: <87y0zk9y4h.fsf@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 72AF42000B X-Rspam-User: X-Stat-Signature: cmx3rkc3otkacfzg1fjkgfedtpdo5fhf X-HE-Tag: 1736412173-895264 X-HE-Meta: U2FsdGVkX1/s3jwutgDaENJy7HUCN6yI9hJBREwdPeAtqx3M7akN+wCcXzW5+o/2+zysuTWtERYvMW0f+b/+zqQEzJlxiG+yj5DxoHBs0yiZ2Wpi0Dxiu+IRmC7vcQS6pPDosdBu5mX/vV2040r2BSYub3WduRAm8yn+b7nYzE4Fjp3ueY8mxYcPv8xH1Ysm2Rcwb6M+95U38+jrVjfL15xRLFTu5sCpIWBKrcG1imTMl3NKcEA73bELxPCX4XjQkhzzg5Y3LUnIyHDqb1WkRZ+ojmK7ttzvR+mC82eRBpWEv64yo5mMDORAZ7zXNLqLjvLw1b77fvpEl5AvGc1sB0LGDelmxtNPZn43DKNOCxFy2i2DutyrqliYej8Y21LbfdoL2iHoAxN01CX0GUyNsSgMQcfrjqTmDsdTcm6lT47d+bzDXsbrk0SRwJ/1Gb7G5FsT+mOnqZsq1XTmsqxZalHh9vKhxu+j9NYWxNFb6SmhO1ThZfovOYOxA4NNEkedv+0IW2C+k9owq2XBZdrQEHu4jz6HD/2vtd2AQ3AIs1NJHx5o1ZOF5dQO8WyIxyRkQwOehasO9IQURK6gkWuLXRAMyAU5uQYsn3Ks3DUA+g7Q4rlvTg747E/Sy8yzBfDrwF9+AQFC24IvpIq+6AN6Cuxok1CsM5XhNDEKZAJDw4K/o3gX5iMNn+2Xr85J+Lk3AWO0FKIo/mtnEFJ/CadMjhnmX7FkBP3BL7bEKz0JHacAtW4DF1iDfnjBKVk0lE4eg0Z49VAFSmjDtLufNZxpSoor4bMZFES3Lk5TPnWqxJrFjhOtDAHsx4Gv7WVwfeAtSl1FwmZJTO6cxZbq41cjwbOum5Q9TbzVLCsLh06VUmKJ1E+WLy4W5WnCX6dNswMUYqOiSLtvw9fZEbjqUQQsjUiKBfVJRvj4Co5R4AVF0XDct4e5PILo9UbIM4X+2KNaRUOUdnRV6eH9TMjbKfM ORGtKKpL RRnCs5SGmSu5Q9FHFrApoSwj+VaqvejvSDuPV8nAx9F3NnxpYWb17toZAvyglUMwiPcb2s7sdsBxPtNa9oxqQI3W9yL4wCQgPJ8CLertDsYBoa5Zc59ZeiR/1sal/B0X/shp8JSZegBcLbqOGiP/Rx+RBWX0mWnTHg9sxjiGYVc0LyeCmf4h7YANHop9njGAmj+Y/jNPU8KLdV13qranYdTKqan3Q5S6oL0YQkQF0G4NWiEsKeCSAM8vYcHT/e7WnznIMQQmaWfyu3dW6NZZvRqPxg7+l04BA0hhs9f7bgQhR1eXIDEQZlVOWo1WnqeWVd8TTg46gu5qwCLxZ3c2ZCSc9Mg== X-Bogosity: Unsure, tests=bogofilter, spamicity=0.476718, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: "Alice Ryhl" writes: > On Mon, Dec 16, 2024 at 3:51=E2=80=AFPM Andreas Hindborg wrote: >> >> "Alice Ryhl" writes: >> > +impl CurrentTask { >> > + /// Access the address space of the current task. >> > + /// >> > + /// This function does not touch the refcount of the mm. >> > + #[inline] >> > + pub fn mm(&self) -> Option<&MmWithUser> { >> > + // SAFETY: The `mm` field of `current` is not modified from o= ther threads, so reading it is >> > + // not a data race. >> > + let mm =3D unsafe { (*self.as_ptr()).mm }; >> > + >> > + if mm.is_null() { >> > + return None; >> > + } >> > + >> > + // SAFETY: If `current->mm` is non-null, then it references a= valid mm with a non-zero >> > + // value of `mm_users`. Furthermore, the returned `&MmWithUse= r` borrows from this >> > + // `CurrentTask`, so it cannot escape the scope in which the = current pointer was obtained. >> > + // >> > + // This is safe even if `kthread_use_mm()`/`kthread_unuse_mm(= )` are used. There are two >> > + // relevant cases: >> > + // * If the `&CurrentTask` was created before `kthread_use_mm= ()`, then it cannot be >> > + // accessed during the `kthread_use_mm()`/`kthread_unuse_mm= ()` scope due to the >> > + // `NotThreadSafe` field of `CurrentTask`. >> > + // * If the `&CurrentTask` was created within a `kthread_use_= mm()`/`kthread_unuse_mm()` >> > + // scope, then the `&CurrentTask` cannot escape that scope,= so the returned `&MmWithUser` >> > + // also cannot escape that scope. >> > + // In either case, it's not possible to read `current->mm` an= d keep using it after the >> > + // scope is ended with `kthread_unuse_mm()`. >> >> I guess we don't actually need the last section until we see >> `ktread_use_mm` / `kthread_unuse_mm` abstractions in tree? > > I mean, there could be such a scope in C code that called into Rust? =F0=9F=91=8D >> > + Some(unsafe { MmWithUser::from_raw(mm) }) >> > + } >> > + >> > + /// Access the pid namespace of the current task. >> >> Is it an address space or a memory map(ping)? Can we use consistent voca= bulary? > > Neither. It's a pid namespace which has nothing to do with address > spaces or memory mappings. This part of this patch is moving an > existing abstraction to work with the reworked way to access current. Sorry, not sure what I was talking about here. I feel like this comment landed in the wrong place =F0=9F=98=AC I remember taking note of the use of VMA, memory map, address space all over the place. I object to "VMA" and would rather have it spelled out in documentation. > >> > + /// >> > + /// This function does not touch the refcount of the namespace or= use RCU protection. >> > + #[doc(alias =3D "task_active_pid_ns")] >> >> What is with the alias? > > This is the Rust equivalent to the C function called > task_active_pid_ns. The alias makes it easier to find it. Cool. > >> > + #[inline] >> > + pub fn active_pid_ns(&self) -> Option<&PidNamespace> { >> > + // SAFETY: It is safe to call `task_active_pid_ns` without RC= U protection when calling it >> > + // on the current task. >> > + let active_ns =3D unsafe { bindings::task_active_pid_ns(self.= as_ptr()) }; >> > + >> > + if active_ns.is_null() { >> > + return None; >> > + } >> > + >> > + // The lifetime of `PidNamespace` is bound to `Task` and `str= uct pid`. >> > + // >> > + // The `PidNamespace` of a `Task` doesn't ever change once th= e `Task` is alive. A >> > + // `unshare(CLONE_NEWPID)` or `setns(fd_pidns/pidfd, CLONE_NE= WPID)` will not have an effect >> > + // on the calling `Task`'s pid namespace. It will only effect= the pid namespace of children >> > + // created by the calling `Task`. This invariant guarantees t= hat after having acquired a >> > + // reference to a `Task`'s pid namespace it will remain uncha= nged. >> > + // >> > + // When a task has exited and been reaped `release_task()` wi= ll be called. This will set >> > + // the `PidNamespace` of the task to `NULL`. So retrieving th= e `PidNamespace` of a task >> > + // that is dead will return `NULL`. Note, that neither holdin= g the RCU lock nor holding a >> > + // referencing count to the `Task` will prevent `release_task= ()` being called. >> > + // >> > + // In order to retrieve the `PidNamespace` of a `Task` the `t= ask_active_pid_ns()` function >> > + // can be used. There are two cases to consider: >> > + // >> > + // (1) retrieving the `PidNamespace` of the `current` task >> > + // (2) retrieving the `PidNamespace` of a non-`current` task >> > + // >> > + // From system call context retrieving the `PidNamespace` for= case (1) is always safe and >> > + // requires neither RCU locking nor a reference count to be h= eld. Retrieving the >> > + // `PidNamespace` after `release_task()` for current will ret= urn `NULL` but no codepath >> > + // like that is exposed to Rust. >> > + // >> > + // Retrieving the `PidNamespace` from system call context for= (2) requires RCU protection. >> > + // Accessing `PidNamespace` outside of RCU protection require= s a reference count that >> > + // must've been acquired while holding the RCU lock. Note tha= t accessing a non-`current` >> > + // task means `NULL` can be returned as the non-`current` tas= k could have already passed >> > + // through `release_task()`. >> > + // >> > + // To retrieve (1) the `&CurrentTask` type should be used whi= ch ensures that the returned >> > + // `PidNamespace` cannot outlive the current task context. Th= e `CurrentTask::active_pid_ns` >> > + // function allows Rust to handle the common case of accessin= g `current`'s `PidNamespace` >> > + // without RCU protection and without having to acquire a ref= erence count. >> > + // >> > + // For (2) the `task_get_pid_ns()` method must be used. This = will always acquire a >> > + // reference on `PidNamespace` and will return an `Option` to= force the caller to >> > + // explicitly handle the case where `PidNamespace` is `None`,= something that tends to be >> > + // forgotten when doing the equivalent operation in `C`. Miss= ing RCU primitives make it >> > + // difficult to perform operations that are otherwise safe wi= thout holding a reference >> > + // count as long as RCU protection is guaranteed. But it is n= ot important currently. But we >> > + // do want it in the future. >> > + // >> > + // Note for (2) the required RCU protection around calling `t= ask_active_pid_ns()` >> > + // synchronizes against putting the last reference of the ass= ociated `struct pid` of >> > + // `task->thread_pid`. The `struct pid` stored in that field = is used to retrieve the >> > + // `PidNamespace` of the caller. When `release_task()` is cal= led `task->thread_pid` will be >> > + // `NULL`ed and `put_pid()` on said `struct pid` will be dela= yed in `free_pid()` via >> > + // `call_rcu()` allowing everyone with an RCU protected acces= s to the `struct pid` acquired >> > + // from `task->thread_pid` to finish. >> >> While this comment is a nice piece of documentation, I think we should >> move it elsewhere, or restrict it to paragraphs pertaining to (1), since >> that is the only case we consider here? > > Where would you move it? The info about (2) should probably be with the implementation for that case, when it lands. Perhaps we can move it hen? > >> > + // >> > + // SAFETY: If `current`'s pid ns is non-null, then it referen= ces a valid pid ns. >> > + // Furthermore, the returned `&PidNamespace` borrows from thi= s `CurrentTask`, so it cannot >> > + // escape the scope in which the current pointer was obtained. >> > + Some(unsafe { PidNamespace::from_ptr(active_ns) }) >> > + } >> >> Can we move the impl block and the struct definition next to each other? > > I could move the definition of CurrentTask down, but I'm not really > convinced that it's an improvement. I would prefer that, but it's just personal preference. I think it makes for a more comfortable ride when reading the code first time. Best regards, Andreas Hindborg