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 55F7DC02192 for ; Wed, 5 Feb 2025 15:24:29 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id DE54A6B008C; Wed, 5 Feb 2025 10:24:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D95236B0092; Wed, 5 Feb 2025 10:24:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C0FE16B0093; Wed, 5 Feb 2025 10:24:28 -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 A21C06B008C for ; Wed, 5 Feb 2025 10:24:28 -0500 (EST) Received: from smtpin02.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 61D1EA0138 for ; Wed, 5 Feb 2025 15:24:28 +0000 (UTC) X-FDA: 83086262616.02.13A5BB5 Received: from mail-pj1-f46.google.com (mail-pj1-f46.google.com [209.85.216.46]) by imf28.hostedemail.com (Postfix) with ESMTP id 5D930C000A for ; Wed, 5 Feb 2025 15:24:26 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=SPrcThCR; spf=pass (imf28.hostedemail.com: domain of aliceryhl@google.com designates 209.85.216.46 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=1738769066; 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=KGUFj/mah/kn+/uxQ4Btu9bKF0UOsIAWYRzSd3+gFfM=; b=dMXyMd/0v9lf/R7sd4+v5BXk4HK7oW9P4vfW+u+0at8hydds5NcN7Novvx2LlJm65IhqIj VpWGHZrvihT1C9UiGDYhgXz7IhfrS9z9ko/KqHuJT+eQJTgihbVDVDMWWseSrloGF4EY2D jz4qQ5yhcwFq+d36hj7ohZfBdpJeG/I= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=SPrcThCR; spf=pass (imf28.hostedemail.com: domain of aliceryhl@google.com designates 209.85.216.46 as permitted sender) smtp.mailfrom=aliceryhl@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738769066; a=rsa-sha256; cv=none; b=UCIk8Jz6vjXXiTJEHaSkINWpVaN7MWA5zVwqqc0KqH0Z8sCcaDA4ir9bdbEOrLJhPDUYDl rPR8NI5ks7GcJg+C1Zuok6aUdEA3iZT+whZatSpMMubbmGsbWHjw1ApJXkE09+yHC5Dxpy MReDgBSvaRtmcroyR7nEfe0F+AZG8vM= Received: by mail-pj1-f46.google.com with SMTP id 98e67ed59e1d1-2f9bd7c480eso3989493a91.1 for ; Wed, 05 Feb 2025 07:24:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1738769065; x=1739373865; 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=KGUFj/mah/kn+/uxQ4Btu9bKF0UOsIAWYRzSd3+gFfM=; b=SPrcThCRZaZbZn1YkUtx055UL55t2Wyr9L4rfqKFSJ33jFEguD4MppHqf1LPDovAd9 6/AinQlRCKzjhbRtBDfPhPj86dboqQCDih24988eV7ab/m/mIhvUDVxzXRuHXWlo8w8S q/dJAQq+z84LO4Nlt7RtOmJGMPq+y3LGgaXzpvp8hRq9lE+wHVwW9kbIoS4q1HfFe0iO mZwvwYwOAJb4Ks8FO/8+k8lvt3PSzXWrq7P5NAfUHprZPlHJ37ra3RLsWRMGyaynjQGa 2urqEcYfm//a+v8IvRjl2jmuia1FlSg4oZRDj9mHJj2KTSV6c7NMsnw0Ndm7jdRyHcmD yHng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738769065; x=1739373865; 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=KGUFj/mah/kn+/uxQ4Btu9bKF0UOsIAWYRzSd3+gFfM=; b=W/TH7DcRG2k+CNiE+l2FjHS+2wp/Z9YVh/LxNYnms8oVexeeyler5V1Q/TsPZUR4ZU sb6ESGjFF28a35axYqdaNZpoyDnmvmOajhuwSN5/DsdVD3mEz0FR1WH0Pybb/K2RdR+8 jco+sGdTe7TJAzOlL0pNgmEPhaYG1wPCFcppHXKViecFYRyGJxzPGRHQVYwAU9QsxUT1 WuX680K5sMZrsmVay6i8KXF9E/P4bFD+bsGZEoGLICCo09y6ivZafL7H2cf0b9t2PX52 60Ojlo/ud3ouv3t/pd5HEmtO7+kzzjtLohlxyx5Sty3CsddMrTTsHFQW7XGamwNpxK/N l3ew== X-Forwarded-Encrypted: i=1; AJvYcCWiwnf4KCeMdL7eFshnk1pU3JbjqxPbRjh5UUd/jw7wmUTG7Ep1vs82fVd2NelHH1HO7mkQDBhNwA==@kvack.org X-Gm-Message-State: AOJu0YwAEbXoaMABAbPZYEkQF07PnCRO/obvtF2ZxvfldUWd2xGS7OL7 cFwEgA7+sjnOarrst7ao9nAoVZdkkOAmG0dsGbrV12pFxH8f3he49tZpsPCTC/pfTMNUNtL6jA0 QqEHHmkIhQvpG/jr3i6p6aJw9Qao7qZs8G/uyv1AaRWjKhvxpOw== X-Gm-Gg: ASbGnct9z7F1ZAik6Wfsui0Y6tVtYkDLmYfLX/KWypPyCJQb0OX4OiFBbjYh9LwxLC9 BPH2+Ml1EegN/9dw6n/W/bIIQPiuQwtwhkBumHoiRaBzqJntMB2nmYOzqHhkHZ/5o15TSgUyr+E vwDX7Z0114dPKQ1WNzjxaQ3l/offw= X-Google-Smtp-Source: AGHT+IFbR/Za3bzQ561Moir1l01pSJAcHP+agVl6hNv1WMjaZabDacA+FBKaP1s+i3G2zvW5BNr6B5Ren6dXC7QGv6w= X-Received: by 2002:a17:90b:370c:b0:2ee:c91a:acf7 with SMTP id 98e67ed59e1d1-2f9e0753763mr5096043a91.4.1738769065057; Wed, 05 Feb 2025 07:24:25 -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 16:24:11 +0100 X-Gm-Features: AWEUYZmq_vX8tVFSj3KjtvPi2OOSFFsq6QpKo6Pfs-lOXylEZQu2sCfVDes0wgA 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: 5D930C000A X-Stat-Signature: c9yqktn19iw834pdoijop46s574frm3b X-Rspamd-Server: rspam08 X-Rspam-User: X-HE-Tag: 1738769066-621740 X-HE-Meta: U2FsdGVkX1+rHzDIB/b1Rzo0eOJkRPq9MgFzG6O5clfPNa/3HB4eIQwQ/KVErVdp38tgFKWswJyrGRrGn2FA8dR/oAS+h8xNwVnYmws26t6YyDZk6djMqmjtIh29H9gUx0pDx6DT8ue1gfQluf9xvtera5OYsb0xldOFtYKVsVe9rbw6UCGaVFwqCaK2KpAk04gGrloXFznkljpZc+3t8IrJHB9+cJ9BH9S00cNUyFtuGG+gpYr5aOMVUAcr8/ntlTxoeqHkhnnW3V2rZL4QqbwQj+ao3J5tua3mDQkL3AIuNgWvMokI/GHlQ8W4h7VyPJhV/L0c/Inazb90vSVFEslEwRjvmcK+fwiw+eZAYJyO8ztNqOrDI2uh0XpWkCQz1DQZ2Z/TixRikz2Hv6Bv+9rbTWwxQnQiI+YVP7QHSwmuF3QxStIGxn/qpXIJvOeKXEUWftfhRQ6TyzMQeHxaCDwr72beKy3FmOLxNJ7xvhlabgjKFL9TWShWR8pZEWTjNNyWLfb6cuxdmZtlXzCgGzVqDZVshbvp6M7g1ZsIERd7zJp0gSM5JF0ejSmhUYU3rcq5g7rEaXEWIdVbcfsxjixRuuK0Dt4fhV+BEb9kXv/xkRj8ticDqBh5SPvpyM84M/q/ifZX6uVID6tkQVhlgr8n6fqfXthTRwAs5IyQOkN7CB42PBox/EkXwalPmzC4ViJvRKpOVLAPFL+zeo6yn4rFZSbqxG3WD5AyDDToxrygUS9HgVzEM8ecBGjqKzmY6aL0Ptopl/oucbjMf4IQAd2J4vrIZCFIp8FK/HmYVE+zcwWjxDZpIvlk8LAuYKliONsqAb7dL0DBLMyVn9sfM2D+O3Vm6owuBrgbMnatOFRSr7aSDYVARlliPNOSo4aqT5sqQGAIhL/Mb/ti161JJh3RDGWZNafiwzhp3GcpOTpc9hZkOTYnbXUMCkVE2KDDsMgO9QUxbks6ccZs8AA a6LMpwNr jkUnScoW3sA+EYj69nKn/LYcIhRSZHgi8cC9GJ9Uw1yxllTTkw9S40AaWNU+c3VboJzJ0QEwFuq4/W4hvLYkcqV2dtT6AEZpLuuP/H1Tftgd9qIVvEpkEybhnwq5JRLAzI9JRzcXuHjG8FILR7ken/0pR/vM6nQHwCirUZ41b2DJMkwe7/ltDViu+lD+Xc0SeIcI2mZZjIChmwG6fGXy0k4UWStgvKZoB5SD4WYfX6j+xIuvG7rLeZKSFBQxaQSWaXkMKCrm0JIojxMK+1ofGy/l7m11rakEcTCF65db5vDH9VpaUc2Qtvz1F+V9rHPxOGtRFl/0TwLi7AGnA6tRaBziHjQsmKBgEbi3L5rCs49eJM/0= 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 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 foun= d, so the pointer is valid. Furthermore, > > > > > > > > + // the returned area will borrow from this rea= d 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 and p= er-vma > > > > > > > locking recently. We are now able to look up and use a vma u= nder the > > > > > > > rcu read lock. Does this translate to rust model? > > > > > > > > > > > > > > I believe this is true in recent version of binder as well? > > > > > > > > > > > > Yes. The safety requirements of VmAreaRef is that you must hold= the > > > > > > mmap read lock *or* the vma read lock while you have a VmAreaRe= f > > > > > > 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 holding = the rcu > > > > > read lock, but you should hold the vma lock to ensure that the vm= a > > > > > itself (and not just the pointer) is safe to use. > > > > > > > > Hmm... To modify the vma, you must hold the mmap *and* vma write lo= ck, > > > > so holding the mmap read lock prevents mutations? > > > > > > Sorry, I think I confused things with my answer. Your code is fine. > > > The phrasing of the "only be used while the mmap read lock is still > > > held" made me wonder about further clarification on the locking here > > > (because the locking is confusing). > > > > > > Yes, mmap read lock means there are no writers that can modify the vm= a. > > > Essentially, you are using the lock to ensure the entire vma space is= n't > > > changed during your operation - which is heavier than just locking on= e > > > vma. > > > > I could extend the safety comment like this: > > > > 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. This > > ensures that there are no writers because writers must hold both the > > mmap and vma write lock. > > How about just changing the last part to: > > Furthermore, the returned vma is still under the protection of the read > 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. Alice