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 206C3C02198 for ; Wed, 5 Feb 2025 19:12:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 89549280014; Wed, 5 Feb 2025 14:12:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 81F65280003; Wed, 5 Feb 2025 14:12:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 670A2280014; Wed, 5 Feb 2025 14:12:55 -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 456C8280003 for ; Wed, 5 Feb 2025 14:12:55 -0500 (EST) Received: from smtpin26.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay04.hostedemail.com (Postfix) with ESMTP id 5D5EA1A0868 for ; Wed, 5 Feb 2025 19:12:54 +0000 (UTC) X-FDA: 83086838268.26.82E29CA Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) by imf05.hostedemail.com (Postfix) with ESMTP id 8DD94100005 for ; Wed, 5 Feb 2025 19:12:52 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=UA0aWQED; spf=pass (imf05.hostedemail.com: domain of aliceryhl@google.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=aliceryhl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738782772; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to: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=SDYGos4YuyhkmJWBTPLxeqNYUYDiehcz7TwhBHBC6OM=; b=HVJgsKZQgLLqA2tWsElpyHbA3sNojMzNBgxhrLbCkVXA+SctPtQ27gx9hvEC0s+/cD/YKC Q0lOmUmleEVo67+bkPR1Rm0RBrC3wXqiEfCD8UlMCIZA9JYKX9Mcu5x1OVFBMkeUcmwlYH BzDuB0TjxVBkrRgbpBeZPEJD93pB41Y= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738782772; a=rsa-sha256; cv=none; b=4y2KV+x8cExiiwi3bWF7DvfSQkdjS48FRS85Xm1MDvRYtEvNKkEfNQKUOpwyDsvITpgWrd ESF9W9G0aDxnNMzmfQXWJBxblVkuYOTAGOto/GjlxtFX1kOBpwhwJX6uWT490BXJG87oUu bXj8rbK5mJT91LcRD3N3KIdfE6+/3G0= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=UA0aWQED; spf=pass (imf05.hostedemail.com: domain of aliceryhl@google.com designates 209.85.214.169 as permitted sender) smtp.mailfrom=aliceryhl@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-21f05693a27so2268275ad.2 for ; Wed, 05 Feb 2025 11:12:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1738782771; x=1739387571; darn=kvack.org; h=content-transfer-encoding:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=SDYGos4YuyhkmJWBTPLxeqNYUYDiehcz7TwhBHBC6OM=; b=UA0aWQEDFonPtKi6Rv9fkECGVuEIKS38aXf2A8Jhle59Rz/Rstfgcxx1ex3F5erDyV KH2f8HqiQEQNdZIl3A8zPLUjZbj0HJpi/8dbTRQ73CQ57qvqF0rap/6ebcpMGH0h6nc5 P9UoKAmEwRzhN/eavxuTCk1OIJihvSdCoB4AmNVjt6qAjqL4uGVP/34+p3uY6TGn5X2j 1rcxxM4DRsq0jS43wOuo2T8zlVypgTUe5PuunQ4OjSCjBA3QqrrA2o/cCZ14JmWx/MDT O1EGfMBESwBEq6XKTxPmst4Hr3kLH4E1heGI/z//9at3HmsxQsxQdOBSp/waRERA8hU0 Dkbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738782771; x=1739387571; h=content-transfer-encoding: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=SDYGos4YuyhkmJWBTPLxeqNYUYDiehcz7TwhBHBC6OM=; b=PN/9+3wk3TE+7Rb27O7IEJ1IBteSLk68AQVKeHRnmmcbuY1Dgbp8BDUTesKT/mew/T xHnB8mLSdCiAF1F5KMrKFS5VLCx1iPRdd6+r0bea/uLzj7m/FFz44jbs0npHqvJI0tjv IiqTeFnHON0mnq1EA+6KTHBc9TupNvq22JOQI5rW5KErYwQK3ugOXm7Uxmp5T3oA33Sg 8L/yl+IVD4QIVg2yVHt4bD3QUX5PhA5/2jOvwxk5Dh3rXUeN1fh5EmVXZARm5NJmoFhz M7CJgrtw+c/35pSBZIBgmRhCFgke/eCFFKv93OQE3T6DRe71oE4UrLMwfKcs/8T/6UUm YpOw== X-Forwarded-Encrypted: i=1; AJvYcCXIpfFrzZDgzXwbOk8Eq+/cl75GOvl51vdupKFTehRnXlZAdiy3KQiRM0vrgritapYYxuZzbI0OYA==@kvack.org X-Gm-Message-State: AOJu0Yz0QVA61boVDrKfZo6/UXVsFmzK7+7QaTEMR1j1cv9eDwomd/JI OwMznIPcOfSnQoKLoB1Pdp6yFTfbqhmQ91kg6cRDddzbHklpO8yGAksGkRwBJZa0FRbsvSF5aEc AlhF6fLdA050oy8Ke6rLQKvIUxXZZbaUL/3x6 X-Gm-Gg: ASbGncv8B7Vdtrc9xrZThwLLovBNCH2OHWuDmJr5lr6kv0jzJttkS4bk0YcLPF1hHlx 92Oy9/AFW7NXKQzx4v9PkjcEtgjUoFyubwE/JyT6Yf5lviJ10ysZf7ikB2tcvb4gThLvMfy1lEQ == X-Google-Smtp-Source: AGHT+IEKSG5yQ9LBWrVpCKsscgav4ruk5XTPVhXGdFOmv0GSC1jxAlCeWwG9SoIcUUj7tCQq87FIyMzqB3TzsXkB/14= X-Received: by 2002:a17:902:d2d1:b0:21d:3bd7:afe8 with SMTP id d9443c01a7336-21f17ed0ee5mr70948535ad.49.1738782771138; Wed, 05 Feb 2025 11:12:51 -0800 (PST) MIME-Version: 1.0 References: <20250203-vma-v13-0-2b998268a396@google.com> <20250203-vma-v13-2-2b998268a396@google.com> In-Reply-To: From: Alice Ryhl Date: Wed, 5 Feb 2025 20:12:36 +0100 X-Gm-Features: AWEUYZnTNTSi-53FnghUxBYk1LwBTRGMDI_5luJmomFNZ8nQjKuFcTubS-458MM Message-ID: Subject: Re: [PATCH v13 2/8] mm: rust: add vm_area_struct methods that require read access To: "Liam R. Howlett" , Alice Ryhl , Miguel Ojeda , Matthew Wilcox , Lorenzo Stoakes , Vlastimil Babka , John Hubbard , Andrew Morton , Greg Kroah-Hartman , Arnd Bergmann , Jann Horn , Suren Baghdasaryan , Alex Gaynor , Boqun Feng , Gary Guo , =?UTF-8?Q?Bj=C3=B6rn_Roy_Baron?= , Benno Lossin , Andreas Hindborg , Trevor Gross , linux-kernel@vger.kernel.org, linux-mm@kvack.org, rust-for-linux@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 8DD94100005 X-Stat-Signature: r66amdmr48nd1ss5d5qcouch9qdmg93j X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1738782772-829351 X-HE-Meta: U2FsdGVkX1+0qbs1AiusHEQfDt4xkzVQ1unLmkAZfMbZtI+vIHG8bG6WLVplayY/TJI2AHj3ZJLc0ArpPUb/EhfQhB+uPgWDjEnAlso/Nu7g271nYRJqLVu/h4cj6Xs9BrId0AbhEi2HNE6rYdF8ZEThFx1JaHZJ/7nw8BwzceMHNo9jsp8MxtuYCVORfwQgWPHhOCvz+l41LJPcmXjS8HKUwrpQg5B9hbDB0oD4wTJHUOCuYNiNKnNTFtRhQ5sm2x4hD0Iz2F2wbyYbaFo9NPBt/3dMNu5Kd/8KVNyY96w7Pgal/wh831Cezlt2RzOi9GNLDetpSVZVr2XwHrOXWhMQCqDFWZpWKgOFP656x0pHfj4QY7N0wGsfPEAuPwzFO9uoX54cOE0pPEYtaX+Qf7B7mgHSDrMppumbkj1woh4O6Hm52bK0tMqPf4YnxU59x9yCbL+tT8bHm9S4y96840pBQ1bBuNEglTZ8tApfvKoOVTSQlvq7t2KteDuOs/D9yUx7mbKlViEd4dH085dvFsUe0IY4/bjg45/zQ/KnyI4q/zEPzHSvIyoy/ENsoiG/tX3HOD9aZlDfRrL6wxHe0/2uVmDaLccFnCWm0tqYpPT4y34KJpMp8Ocgn4PGtZbG2qVKfptjNX7yByW2lsI+U6uGGClrO0EHp3jBEGqa9PiF6J1PYOMvR6N+aROz5fA5Kv/Bv5M8kr/6vGHhfKnLGmYd61VnrafNgSauxuIr03SgYXCXQBtI0fLtNhB+ZRTeazdaAfxh9QCNjri9OwQUBRmg1M1ku/xkdNdhUDtOn1cK5hkEXwoPRg4TT/nRCItc03H7pRskjOvKmbXrSvAiAp/c26Ka9PHUAmgESPYbF7nbgPYrip2jZnuFV3Kov51KpTT3u7AnFvbwVnAa8Li3IXkFYY79+ibW5U2TUAQHbNyigI42JjvTBnZ/f0Ef00E8wsuX1JWr5BuQB4isY4E mieEwBj4 BToN5R9CUiF75qLqJfBZqyWP2yO8+XpJJHbwtoV+3PO9vQ7qvLC1fBZYhjwvFT58KFUIi3t3icc9j2UOIHJDTCmeod6xKYLmty5xXAvizSOblkiXWcGtxfiY7TYiL1PbWZvwMBBu9lUtYxSd+cf33AZ1CTk3X693MagQkJf4TNngijJ88DfDTOyss+mAX50EBuAYXBJXVvZ1U4auU5CtQpF8jAnD47ffDJOwUWwMyuE5VzGoAHp0RPWWAU2Q4GaQs+aiX+6mL44QTuhZXi3Udkyj4RUcJqQoTus9tT9GgHgUgtpnwSxeiXngFC0/SMMPa/xi7bZjljIDPT8Ku6IpzAorGagSZCNc2sE3zgHvwUJE9BUQ= X-Bogosity: Unsure, tests=bogofilter, spamicity=0.500000, 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 Wed, Feb 5, 2025 at 8:10=E2=80=AFPM Liam R. Howlett wrote: > > * Alice Ryhl [250205 10:24]: > > On Wed, Feb 5, 2025 at 3:38=E2=80=AFPM Liam R. Howlett wrote: > > > > > > * Alice Ryhl [250205 07:10]: > > > > On Tue, Feb 4, 2025 at 4:46=E2=80=AFPM Liam R. Howlett wrote: > > > > > > > > > > + let vma =3D unsafe { bindings::vma_lookup(self= .mm.as_raw(), vma_addr) }; > > > > > > > > > > + > > > > > > > > > > + if vma.is_null() { > > > > > > > > > > + None > > > > > > > > > > + } else { > > > > > > > > > > + // SAFETY: We just checked that a vma was = found, so the pointer is valid. Furthermore, > > > > > > > > > > + // the returned area will borrow from this= read lock guard, so it can only be used > > > > > > > > > > + // while the mmap read lock is still held. > > > > > > > > > > > > > > > > > > So We have complicated the locking of the vmas with rcu a= nd per-vma > > > > > > > > > locking recently. We are now able to look up and use a v= ma under the > > > > > > > > > rcu read lock. Does this translate to rust model? > > > > > > > > > > > > > > > > > > I believe this is true in recent version of binder as wel= l? > > > > > > > > > > > > > > > > Yes. The safety requirements of VmAreaRef is that you must = hold the > > > > > > > > mmap read lock *or* the vma read lock while you have a VmAr= eaRef > > > > > > > > reference. This particular method achieves that requirement= by holding > > > > > > > > the mmap read lock. But there is also a Rust lock_vma_under= _rcu(), see > > > > > > > > patch 4 for that. > > > > > > > > > > > > > > Right, okay. Thanks. You can get the reference by only hold= ing the rcu > > > > > > > read lock, but you should hold the vma lock to ensure that th= e vma > > > > > > > itself (and not just the pointer) is safe to use. > > > > > > > > > > > > Hmm... To modify the vma, you must hold the mmap *and* vma writ= e lock, > > > > > > so holding the mmap read lock prevents mutations? > > > > > > > > > > Sorry, I think I confused things with my answer. Your code is fi= ne. > > > > > The phrasing of the "only be used while the mmap read lock is sti= ll > > > > > held" made me wonder about further clarification on the locking h= ere > > > > > (because the locking is confusing). > > > > > > > > > > Yes, mmap read lock means there are no writers that can modify th= e vma. > > > > > Essentially, you are using the lock to ensure the entire vma spac= e isn't > > > > > changed during your operation - which is heavier than just lockin= g one > > > > > vma. > > > > > > > > I could extend the safety comment like this: > > > > > > > > SAFETY: We just checked that a vma was found, so the pointer is val= id. > > > > Furthermore, the returned area will borrow from this read lock guar= d, > > > > so it can only be used while the mmap read lock is still held. This > > > > ensures that there are no writers because writers must hold both th= e > > > > mmap and vma write lock. > > > > > > How about just changing the last part to: > > > > > > Furthermore, the returned vma is still under the protection of the re= ad > > > lock guard and can be used while the mmap read lock is still held. > > > > Well, the important part here is that you can't do this: > > > > let guard =3D mm.mmap_read_lock(); > > let vma =3D guard.vma_lookup(...)?; > > drop(guard); > > vma.foo(); > > > > since that would use the vma after the lock has been released. The > > reason that the above is prevented is because `vma` borrows from > > `guard`, so you can only use `vma` while `guard` is still valid. > > > > But it implies that this isn't valid: > > let guard =3D mm.mmap_read_lock(); > let vma =3D guard.vma_lookup(...)?; > > vma_lock(vma); > > drop(guard); > vma.foo(); > > vma_unlock(vma); > > See mm/userfaultfd.c:uffd_lock_vma(), which falls back to mmap read lock > to do this if rcu lock + lock_vma_under_rcu() is unable to lock the vma. This patchset does not have the functionality for doing that, but it's definitely possible to add. Alice