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 6C107E6918F for ; Fri, 22 Nov 2024 20:17:14 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DC7756B0082; Fri, 22 Nov 2024 15:17:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D77D06B0083; Fri, 22 Nov 2024 15:17:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C3F906B0085; Fri, 22 Nov 2024 15:17:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id AA06D6B0082 for ; Fri, 22 Nov 2024 15:17:13 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 630CC1C845B for ; Fri, 22 Nov 2024 20:17:13 +0000 (UTC) X-FDA: 82814837574.01.8DEFF36 Received: from mail-wr1-f42.google.com (mail-wr1-f42.google.com [209.85.221.42]) by imf05.hostedemail.com (Postfix) with ESMTP id 9E96110000F for ; Fri, 22 Nov 2024 20:15:28 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Zw6sP4da; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.42 as permitted sender) smtp.mailfrom=aliceryhl@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1732306443; a=rsa-sha256; cv=none; b=atenWoV/qhSb6zb58ly/dPYlV7z8O8E5xjkukc2hny228kH6kV97RWNjuV0Fjn29X6RvL5 v8JlUGwmPC7YO5Xnlx+LTZNmUUuam0ndHsunlHsHzxErGVOZoX8YvscC5rHyV1jjR/w9dH yG+jZvQAw6X+vKGRI2v9rpV+Oz8JSTE= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=Zw6sP4da; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf05.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.42 as permitted sender) smtp.mailfrom=aliceryhl@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1732306443; 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=QG3kEeD4o5WMVUrR5MGaMLkHMAvK8n76S6L6z1qKop8=; b=EqDT0az51zBqyUFDp4F4Rfe2meFFqq1NpDnehzZr+XC14/MfJl/TZDJPLae/sX6dmiClfx mb1f43B6dLFc+MRGvyjiiBFMAITx9gEYaJVy0j40CPkxBTznEgnGYUnCETVNP2Ux72FSox SMsv4IdPP0U5gNgDlOjvhqHD/2V1m4Y= Received: by mail-wr1-f42.google.com with SMTP id ffacd0b85a97d-38248b810ffso1756618f8f.0 for ; Fri, 22 Nov 2024 12:17:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1732306630; x=1732911430; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=QG3kEeD4o5WMVUrR5MGaMLkHMAvK8n76S6L6z1qKop8=; b=Zw6sP4dahJQwnaUZeHj28zP5UnHUZnlQ5dCtqqna6gzfPzUfj+EFb3zK+5mIQ2R1dT +lymd/ai7lgbTCJNh0CuyyKT4752fwLOEkNKflRthPhZ0BqK/r1lb5T/qo9iDDPaBcea yN1AVR+leDT6teWnNmOmY+ViSjMpW7+OyPrHpCOeqAlL+IRHExO8GN1gL4Zf0S2eYVlA DhSTBC3C/TqBTiWie4vF/L6r5RGGkOiAE4mA3FbGxSTDEzmR79Z1w8fzAL/OwJW974+o 5X8RlvblHhwccbM9Ob5ujJrCdTWbD88cdv3oYlSVWvK1uUfei2/IBx2d/5ggfHVFD8aU snuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1732306630; x=1732911430; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=QG3kEeD4o5WMVUrR5MGaMLkHMAvK8n76S6L6z1qKop8=; b=lXVVXD4njTViGosBT+Z5NDxtGO5qyopAXMm8XbW44kgoV7h/FUCNQrgxSz87pnLVJl w53ApYld7hGQl9HlvGBVLUvHBQEZDSl2Un1rh+bOgrI9C4IMoI/dkEc0vye9SDVai7D1 2/5PT9r9c8Y9oJAAVNP1uDZ3EeTeamGLwfeSbxMwGapGZY4OmzB8qpaqErQGd45f0bzK 5AmkgjkO4UsINM4s1r3/GtFifhC3NWwQHHwEv0PkM8UdXEm5h+T4ynkFpuxuNupoCiNS OnVnkzQIDGDZAMB/DWRuCdu5V/FmQffW5psTrVP8jyPLNqLV/ybO6ymasYwYgp1TardG 48YA== X-Forwarded-Encrypted: i=1; AJvYcCV+zFrNBikMk9PNxunHyZtksQhxyt9cAFTF1wr58EztF+rhWXbTvM9zpJEE6KFeUQEMvRmQ7g/g/Q==@kvack.org X-Gm-Message-State: AOJu0YyDQS2Z72ItMBy32rw60Xo7knWNisvQY172pDbkss6ZDiC47ObO TURFNwujJ+VE5+jEP76/vCJM2Tf2QPxx7OjSEJGsCfy5XuClDHFpnY3dFyTVwzfm554PA87NNOZ TtQhFHZu7NiSRePnYTul94EdAP9OLUVBscbp8 X-Gm-Gg: ASbGnctm0kp8JDTyKe7J6aj5321sJ4X1Yz7gzOZZgv0gblX4BSIYA04+gs46mBeXZW3 HV2KeEphalxuMShrHh4hUzAxvrHPdr88x X-Google-Smtp-Source: AGHT+IFWqePFuP+tQF+WkpAWE/TYTHdWg7sF/rMtGjGKkKfM5BVl/SGktBjFR20250IpBmxLobH9zw/Mk8zzOzHVBm8= X-Received: by 2002:a5d:5849:0:b0:382:2f62:bd4b with SMTP id ffacd0b85a97d-38260b86b74mr3165216f8f.33.1732306629848; Fri, 22 Nov 2024 12:17:09 -0800 (PST) MIME-Version: 1.0 References: <20241122-vma-v9-0-7127bfcdd54e@google.com> <20241122-vma-v9-8-7127bfcdd54e@google.com> <6740c786.050a0220.31315a.5363@mx.google.com> <6740d8be.050a0220.30b282.4f2e@mx.google.com> In-Reply-To: From: Alice Ryhl Date: Fri, 22 Nov 2024 21:16:58 +0100 Message-ID: Subject: Re: [PATCH v9 8/8] task: rust: rework how current is accessed To: Matthew Wilcox Cc: Boqun Feng , Miguel Ojeda , Lorenzo Stoakes , Vlastimil Babka , John Hubbard , "Liam R. Howlett" , Andrew Morton , Greg Kroah-Hartman , Arnd Bergmann , Christian Brauner , Jann Horn , Suren Baghdasaryan , Alex Gaynor , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , linux-kernel@vger.kernel.org, linux-mm@kvack.org, rust-for-linux@vger.kernel.org, Andreas Hindborg Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: 4rkof8nrubh9zsnhbcotggn75xkufdri X-Rspamd-Queue-Id: 9E96110000F X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1732306528-888624 X-HE-Meta: U2FsdGVkX18Cyt96iZlUPPzI+Hi6DCjklVN5THyIqOHzi9ixjLplgeXC8XvRC8h5JrO4UnXFQa11HVCVwrvCEupJfd36Mi9V/vwTeg8wpEvnLayzb9XQPPRwNtqawGTuQUWz7Civy7yTq2FUtQvP1J2l9TMIMYwqJUzIC+UUbUeGBd/+8tkxMoQNUAWtBaidxaPl8i9r2zTFKy5hErXOG3y7k888+p4d1dfUCrhYmgpEPwqqC+jLISfMOyoCv5UzrE/vyjIURcnFTL+u1gB+czuJ6P6KuFYWHVIZLh3GcU4GyiKWE+QaEWnxikNpqMPma9vHmeI7s6zWY2+9Kf2fxRlEiczBC3zeFHOQCLjmKi0aljrhHZGEP6VKJ5GszINk+0BHEN0uaFPBa+orKo2p+gwZ67qMav+ZPhzFjeUgLqfYl1x4AHB8QbofDPfj6QHnmxvuzWhkt4qe2cAcA11oW6Adj5XuYXGB61TukpLXfma/5OA/u5CSJuTMrmbkduMbkwhb61oEB/fQpcycStROOuzFJbjRMtz1Lj2e+x710/DRV9f6cqdbGwb/XDiBnF1t+lFVC9l8v2CzRoTcQSP6Xqr+ot0Zpg9hDVrYCNzikAVrfSR94mYLbK+NKaoy8h8dNJIeo4s1INhEO6ADzEtrg3BKhFWEczTxXXJYNUFGd0c9afOFjmchx7S5kpHfHtpjz2lyytuj5oLveGFjhfQy3izD8ip3/3od2YAnlx2ahjJsTyidvGVCm28718uMt8qsqTEhv94jMR1NB9QuNteBQz0pStrSjkXzK1AYoVJdMYEY2wV9wIdnCvLm0fJixDy3nNEHxzgX0qQ26LZ57UUAJAcEwCKdMDfJtukxxQI6j567lh2iDA5xgld1N8RDlH+UyzVON6FyCptASPHinr2OaThLWKRoHTQgbw91jnDCHfDwnc0kdeqrh16BWGno4g13rjxILmpS02Mtw2kkQFY 0yWP2vM0 +TlvfWPlUk0QMJCJ47cNUZpc3ouWoM6WhrybrDkhHAdX18p3Vd1y3jQd6Dh1tH/L07JxdydoJPgdfc1OJQSeHPExvg5YjdczS2sPgONgPetpAOqRzJY20oqnd6G50ZbaeoSSKjQn9UIN9Fmv2O1+EMzRoHCcoTLLOmHHwvqX50i4pM0fLG7W8PHJWVzdHC/gXZXoBMU2vgqrQaZudxXfeLgahXgTQC7AYLw3Wj5DAtB6P2UNVJ/FAz/QtV4BumHCHtokDOTSNBv59JK+F8FEtZaqjlSKyCY0lh6z3E/A0+IH3j5h7LBBfq8wr68f/qSTdq/pwqECWf5h+3gDU3WIzqGDECsJn2c9YLaqpQsgXu0gNw8c= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000001, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Fri, Nov 22, 2024 at 8:54=E2=80=AFPM Matthew Wilcox wrote: > > On Fri, Nov 22, 2024 at 08:43:33PM +0100, Alice Ryhl wrote: > > On Fri, Nov 22, 2024 at 8:30=E2=80=AFPM Matthew Wilcox wrote: > > > > > > On Fri, Nov 22, 2024 at 11:17:15AM -0800, Boqun Feng wrote: > > > > > I don't think this is a problem? As long as a thread exists somew= here > > > > > with `current` being equal to the task, we should be fine? > > > > > > > > > > > > > I think I had a misunderstanding on what you meant by "operations > > > > that are only valid on the current task", you mean these operations= can > > > > be run by other threads, but it has to be *on* a task_struct that's > > > > "currently running", right? BTW, you probably want to reword a bit, > > > > because the "current" task may be blocked, so technically it's not > > > > "running". > > > > > > > > Basically, the operations that `CurrentTask` have are the methods t= hat > > > > are safe to call (even on a different thread) for the "current" tas= k, as > > > > long as it exists (not dead or exited). In that definition, not bei= ng > > > > `Sync` is fine. > > > > > > > > But I have to admit I'm a bit worried that people may be confused, = and > > > > add new methods that can be only run by the current thread in the > > > > future. > > > > > > I agree, I think CurrentTask should refer to "current". Or we'll > > > confuse everyone. Would ActiveTask be a good name for this CurrentTa= sk? > > > > I mean, it does refer to current. Any time you have a `&CurrentTask`, > > then you know that you got the pointer by reading the value of > > `current`, and that the task you got it from hasn't returned to > > userspace (or otherwise exited) yet. > > > > But the name ActiveTask also makes sense I guess. > > OK, I'm going to be all rust newbie about this (zoea?) > > Given that there are operations that we can do on 'current' that aren't > safe to do if we pass current to another thread, is the right thing > to say that we have Task, and you can get a (Rust) reference to Task > either by it being 'current', or by getting a refcount on it using > get_task_struct()? And I think that's called a typestate? There are essentially three important types here: * ARef * &Task * &CurrentTask The first one is using the pointer type ARef<_> to hold ownership over a refcount to the task. When variables of type ARef go out of scope, put_task_struct() is called in the destructor. And constructing a new ARef involves a call to get_task_struct(). Now, the second type &Task is a reference to a task. A reference is when you *don't* have ownership over a refcount. They're used whenever there is *any* mechanism keeping the value alive; the actual mechanism in question is not part of the type. The way references work is that they are annotated with a compile-time concept called a lifetime, which is essentially a region of code that the reference is not allowed to escape. The compiler generally enforces this. For example, given an ARef, you can obtain a &Task without touching the refcount. Attempting to use the &Task after the ARef is destroyed is a hard compiler error. In this case, the ARef<_> keeps a refcount alive, so accessing the task through the &Task is always okay even though the &Task doesn't have a refcount. Another mechanism is `current`. The way that Rust's `current!()` macro works is essentially by defining a local variable which goes out of scope at the end of the current function, and giving you a &Task where the reference's lifetime is bounded by that local variable. So by ensuring that the &Task is bounded by the current function scope, we ensure that we're not using it after current becomes invalid. With this change, the `current!()` macro instead gives you a `&CurrentTask` whose lifetime is bounded to the function scope in the same way. Given a &CurrentTask, you can deref it to a normal &Task with the same lifetime, so you can also access the normal Task methods on a &CurrentTask. And what's happening here is basically that ... you can use the &CurrentTask as long as the function you created it in has not yet returned. So if you spawn something on the workqueue and sleep until the workqueue finishes executing the job, then technically that satisfies the requirement and Rust will not prevent you from using the &CurrentTask within that workqueue job. And this is technically also okay from a C perspective, since the address space isn't going to go away as long as the function doesn't return. Alice