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 58BD7C02183 for ; Wed, 15 Jan 2025 11:03:57 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C06756B008A; Wed, 15 Jan 2025 06:03:56 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id BB6BF6B008C; Wed, 15 Jan 2025 06:03:56 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A56C26B0092; Wed, 15 Jan 2025 06:03:56 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 832BD6B008A for ; Wed, 15 Jan 2025 06:03:56 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 2C28A8131C for ; Wed, 15 Jan 2025 11:03:56 +0000 (UTC) X-FDA: 83009401272.03.7D5CAA1 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf04.hostedemail.com (Postfix) with ESMTP id 85FDE40017 for ; Wed, 15 Jan 2025 11:03:54 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ALRZgHh4; spf=pass (imf04.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=1736939034; 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=q7VpIVphowv/+6XHcukfcIJsqCRnBixghilCBKxQT68=; b=THS9pP0E9FgwNSCyZJd3u9L1iuUsznyy90+m5dswtYNzFGNGtt9Ug03tGdEq/qs2kJIcdD cqyQFzJMGvypfaCVRLApW7WYhttUa9uaZ3LUvV9ofjjl0hPiMuc3PhETM6nWrKpuDUy/94 upNYNoMgy6SHZgxeuObT3q9jYssJ4s4= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736939034; a=rsa-sha256; cv=none; b=Mz4p4Tkgdg4aKACEq0+W1rtIsec/r5lgMoF/xcfNwDwCICrJOkvQgiUGItR4qHlp0TQXxS 65J/8KnwMuZKsJr+Fm6v6UFV405fPNhvpXrx3fduDKgB8I4OXmT0uED7fRZCgjXfWh0BVW f4BdawiLJAEupgoKltNz4rD6v1QGu3I= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=ALRZgHh4; spf=pass (imf04.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 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id B3167A41CEE; Wed, 15 Jan 2025 11:02:05 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 960A9C4CEE4; Wed, 15 Jan 2025 11:03:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736939033; bh=iM/ufShMeANIyjcRrOoDegM0Bsoxs3dzLR1kEoW8C1w=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ALRZgHh434RCRIA1UqIBaRe/NXU5ncICjYcBki3iZ6LnjUIawa2s8VKqZyIZRYOuw MKGss0LBMtbskZgwNACkZFv5CxjQtGpgCnOPa9uItyYDaYQgezoIgOq06CfZkc1cHZ +OsOyCsOwCRENcvgLkSuTQVsxMUTh0cATzjMq6gLyzdMljiSG8QjiXuEzUtYrAO2Xc TZhHHGxB1dGTm+Fc1bPvu8mIySILB9BiieQhrJ/S7sxK9XYeRj+3H1mQga7+Nto/Hy wB7b5z0a8Lg7lzV1QZWuHwcCTqv1Qk987A1M5B7/3rLz8d9f7awGU00Td5ZSjpM/kC szEO2vMKlAvaw== 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 "Mon, 13 Jan 2025 11:26:42 +0100") References: <20241211-vma-v11-0-466640428fc3@google.com> <20241211-vma-v11-8-466640428fc3@google.com> <87frmnadmk.fsf@kernel.org> <5qXA_x0NK0TzOkDwdQ8RYbk3SboUQiD0qflQhsoPRyhFxpD7fZHC7uVjI7RQBvvHPVEO1zlMRBq3F8BBImHrYQ==@protonmail.internalid> <87y0zk9y4h.fsf@kernel.org> User-Agent: mu4e 1.12.7; emacs 29.4 Date: Wed, 15 Jan 2025 11:24:23 +0100 Message-ID: <87frlke5ns.fsf@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 85FDE40017 X-Rspam-User: X-Rspamd-Server: rspam07 X-Stat-Signature: fbnw31ruqzwsjaiut9jyduuww3tcpqty X-HE-Tag: 1736939034-565722 X-HE-Meta: U2FsdGVkX1+EBY8RpRX2LfUaRaC0TS62MPRrsOpVUfkDFqKhGXjsYza1cV5ykQKB4tDpMfy/GWp+W5mHotHvSC3SW9N9LcDK7U588P4Clj4Jj9ogZJYaeLZsX3tCwsRtgXxgzed+QO3eZyWI/kjPEnipUv14BUaaypozQRaxGadUP+2AY4GWP1B1XVQQ0vRbebZ2NsMbR4T33+H45G3leM/ZQJyMjRFX1FoRpN4dt+gc6V0nvD+cRszRriAORJXOw8bwwkYjgXtQb6OWOuDj2ErzRTuFcandI7RqvV+8Rl+ZslVKD6vBoKBsrQc6Tb0MSqkV6b6b3Mftz9YlwkOZPA+L7INV2+bx3aUQV6OwtsOh2woPCCkp4ew9+OAv5xPUXiITxMqsl/4jPn/W7FlgVN317iuXnEJtPshU7P5AtmWcEkUFknvRAWn+1wo92bnpX4fwpi5BXky7d1h1K/4FhvCYiYDAvW5rZrKi4Ozg4VgUDX2kdCbIByIEQfx6p/q/DdUSeG4YQUW866pHqISYlHHH+B15DmoX8kNHCCE58Ppw4Pzo7TwAmBjkg/XQcqGIysJjjJDXL9FiVh+fPn7+97g93VAs2gl4DHiV+PDDUI3IFk3jINj1iyneH25zxfhurn9f8YPKzzIE3qyLTd8FCnfd091/+8/LAX0udKbYg8mV7lUVOpuQZnnmt1dR8sRULfdXxiW+rYq0xbHddVffOCUoGfwtz1W+FoIE0LmftkQWPeAQlO8uOowsE/IahRnCBWQmfe2H52jRd2YcUSLPlT5PQ/TyERRjXX8nwTogw7hc7yMp73hQnSvYUB8oGykxVrnaTcIf1/D2w+8vBpzvWkXi0WfcgYxCidvdUrUR2pZ1kQJWoSC+LdsgeoOHnx3kmjtWVriTwxky1Yk5Qjq1e2j7NZxpVLNA3M3HbEWzpG4KBldP3Sv6IwQOw9LkdyDuV7Mv/WyUAtQq4SYc2Q0 mfskSJCa aSa/aGjBsLJQVgxcXk9UgNq395IUi4ijNVXGvKFy7xeiPwzMv32tkP6U9/Oyf9WSLAgtX/NlnSQ+x7Jl1KymeJr1pYyXbFrooQWp2krWXL/2kN1kQWBpF5sb5+ed8aYZi8qFlLcAGrdyI444Eq7QLaxScRYbmAzwpHkkMfLxFFfORvw9f3f1nzTPokvgMG3rxm69S9gwWqU5YislpwevWy+e95C0jN9QenOEaHfo99GyZ0JQek+XHt6Vi0hLmdGmXY2iaxJVT511bLdtfPT4zWjcfHTO2tchKC5q5P6O3ixbUM/mItWSgSbx4kjhQZnmNanTzlzUvAVeorQWnRW/wYNgd4Q== X-Bogosity: Unsure, tests=bogofilter, spamicity=0.473796, 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 Thu, Jan 9, 2025 at 9:42=E2=80=AFAM Andreas Hindborg wrote: >> >> "Alice Ryhl" writes: >> >> > On Mon, Dec 16, 2024 at 3:51=E2=80=AFPM Andreas Hindborg wrote: >> >> >> >> "Alice Ryhl" writes: >> >> > + #[inline] >> >> > + pub fn active_pid_ns(&self) -> Option<&PidNamespace> { >> >> > + // SAFETY: It is safe to call `task_active_pid_ns` without= RCU protection when calling it >> >> > + // on the current task. >> >> > + let active_ns =3D unsafe { bindings::task_active_pid_ns(se= lf.as_ptr()) }; >> >> > + >> >> > + if active_ns.is_null() { >> >> > + return None; >> >> > + } >> >> > + >> >> > + // The lifetime of `PidNamespace` is bound to `Task` and `= struct pid`. >> >> > + // >> >> > + // The `PidNamespace` of a `Task` doesn't ever change once= the `Task` is alive. A >> >> > + // `unshare(CLONE_NEWPID)` or `setns(fd_pidns/pidfd, CLONE= _NEWPID)` will not have an effect >> >> > + // on the calling `Task`'s pid namespace. It will only eff= ect the pid namespace of children >> >> > + // created by the calling `Task`. This invariant guarantee= s that after having acquired a >> >> > + // reference to a `Task`'s pid namespace it will remain un= changed. >> >> > + // >> >> > + // When a task has exited and been reaped `release_task()`= will be called. This will set >> >> > + // the `PidNamespace` of the task to `NULL`. So retrieving= the `PidNamespace` of a task >> >> > + // that is dead will return `NULL`. Note, that neither hol= ding the RCU lock nor holding a >> >> > + // referencing count to the `Task` will prevent `release_t= ask()` being called. >> >> > + // >> >> > + // In order to retrieve the `PidNamespace` of a `Task` the= `task_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` ta= sk >> >> > + // >> >> > + // From system call context retrieving the `PidNamespace` = for case (1) is always safe and >> >> > + // requires neither RCU locking nor a reference count to b= e held. Retrieving the >> >> > + // `PidNamespace` after `release_task()` for current will = return `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 requ= ires a reference count that >> >> > + // must've been acquired while holding the RCU lock. Note = that accessing a non-`current` >> >> > + // task means `NULL` can be returned as the non-`current` = task could have already passed >> >> > + // through `release_task()`. >> >> > + // >> >> > + // To retrieve (1) the `&CurrentTask` type should be used = which ensures that the returned >> >> > + // `PidNamespace` cannot outlive the current task context.= The `CurrentTask::active_pid_ns` >> >> > + // function allows Rust to handle the common case of acces= sing `current`'s `PidNamespace` >> >> > + // without RCU protection and without having to acquire a = reference count. >> >> > + // >> >> > + // For (2) the `task_get_pid_ns()` method must be used. Th= is will always acquire a >> >> > + // reference on `PidNamespace` and will return an `Option`= to force the caller to >> >> > + // explicitly handle the case where `PidNamespace` is `Non= e`, something that tends to be >> >> > + // forgotten when doing the equivalent operation in `C`. M= issing RCU primitives make it >> >> > + // difficult to perform operations that are otherwise safe= without holding a reference >> >> > + // count as long as RCU protection is guaranteed. But it i= s not important currently. But we >> >> > + // do want it in the future. >> >> > + // >> >> > + // Note for (2) the required RCU protection around calling= `task_active_pid_ns()` >> >> > + // synchronizes against putting the last reference of the = associated `struct pid` of >> >> > + // `task->thread_pid`. The `struct pid` stored in that fie= ld is used to retrieve the >> >> > + // `PidNamespace` of the caller. When `release_task()` is = called `task->thread_pid` will be >> >> > + // `NULL`ed and `put_pid()` on said `struct pid` will be d= elayed in `free_pid()` via >> >> > + // `call_rcu()` allowing everyone with an RCU protected ac= cess 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), si= nce >> >> 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? > > The function already exists. It's called Task::get_pid_ns(). I think > the comment makes sense here: get_pid_ns() is the normal case where > you don't skip synchronization, and active_pid_ns() is the special > case where you can skip RCU due to reasons. This comment explains that > normally you cannot skip RCU, but in this special case you can. Reading this again I think it should simply be cut down in size: ``` The lifetime of `PidNamespace` is bound to `Task` and `struct pid`. The `PidNamespace` of a `Task` doesn't ever change once the `Task` is alive. >From system call context retrieving the `PidNamespace` for the current task is always safe and requires neither RCU locking nor a reference count to be held. Retrieving the `PidNamespace` after `release_task()` for current will return `NULL` but no codepath like that is exposed to Rust. ``` The rest is not relevant to this function and it does not help understanding the function. Another thought - add a link to `get_pid_ns`: @@ -307,6 +307,8 @@ pub fn mm(&self) -> Option<&MmWithUser> { /// Access the pid namespace of the current task. /// /// This function does not touch the refcount of the namespace or use = RCU protection. + /// + /// To access the pid namespace of another task, see [`Task::get_pid_n= s`]. #[doc(alias =3D "task_active_pid_ns")] #[inline] pub fn active_pid_ns(&self) -> Option<&PidNamespace> { Best regards, Andreas Hindborg