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 9E09BE77188 for ; Tue, 14 Jan 2025 13:42:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 07A3A6B007B; Tue, 14 Jan 2025 08:42:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 02AA56B0083; Tue, 14 Jan 2025 08:42:21 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E0C886B0085; Tue, 14 Jan 2025 08:42:21 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id C3B0F6B007B for ; Tue, 14 Jan 2025 08:42:21 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 1CA871209F8 for ; Tue, 14 Jan 2025 13:42:21 +0000 (UTC) X-FDA: 83006171682.30.CF3E565 Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com [209.85.221.43]) by imf11.hostedemail.com (Postfix) with ESMTP id 173C240006 for ; Tue, 14 Jan 2025 13:42:18 +0000 (UTC) Authentication-Results: imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=M4c3wXW8; spf=pass (imf11.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.43 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=1736862139; 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=W797SlhZRezIDTbO73i8Q0Q5i2usqolq33m4T/Z6rco=; b=gbIGy3GF/8CzMt6p8e+J4VLH/A5ck6iWlOcGSDGg+03aMd+EGhPorKI3EOp+mxW3LbFkYI fGPpQ5ueQy1zCwZmoVaFMns5RfO8DABA66UX/38ZAG+mPrCXAPs0Z6dagb8/bq8hSQmfAz 7M+36zh8xQat9D7oAbPq1VYY8KxXoKw= ARC-Authentication-Results: i=1; imf11.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=M4c3wXW8; spf=pass (imf11.hostedemail.com: domain of aliceryhl@google.com designates 209.85.221.43 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=1736862139; a=rsa-sha256; cv=none; b=cLPpg0deCaCSIuSAnOmALRBuVxhTIK4tHaHORZPQB0WWgn0HQ6C+jeksEgzAKPgGkedrgn PLo4mRs9p3kudZ9lzhWPVG9pvySuvTp54MUROWeyYXRqNVfja4J09Fy+9we54rgW6bEEv8 yL+yUih47w1EOLoj5ptEHQVWX3HwnHU= Received: by mail-wr1-f43.google.com with SMTP id ffacd0b85a97d-3863494591bso2941383f8f.1 for ; Tue, 14 Jan 2025 05:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736862137; x=1737466937; 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=W797SlhZRezIDTbO73i8Q0Q5i2usqolq33m4T/Z6rco=; b=M4c3wXW8woA4cRIvcfKYeX1GozHaYnp4Ubne0+a2o8LUKqRM2dz9uTkcZxdmJEgZgD 5QGT9PSLdN5HgHv7+44BsE79vyzd5SiETd7h/UzLgqjLlJwgPbohll3cFylQhsaUNWXz jmCPPw1AFgTUAzJCZ7uhe0/nyTpek3JTvDIW/xYCsximaA6PBAZw8q3/D9dVeQ8MgIyL PPIIi6ydn0Ktp1hZcqSYolpSkosxNKlek9XeNyAMkrqCXkmUknwXSPYP2jphm7Jnpi5Q B2oqFwX2B6N7oUxmGDHefMeo8owSehbaoPkqRucsJ4ZyAosnKWAytFjf5XU7vvNIsfxQ bPHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736862137; x=1737466937; 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=W797SlhZRezIDTbO73i8Q0Q5i2usqolq33m4T/Z6rco=; b=rB124aUSPS9IsAI0vXiGDlA63N68Bp5o6MZS5/kVGXmzia/p83F7SDAqZrah9SCyAq FJ8JrliwdzO35YtAuvm0tAB5lmTPaevWYsUoZrK3YZejyll8pj4GgEnUERcxFepe81cU 9ByUdE5b2KPK9hn4o5LVW3SR0F2gg7pL9+ERruNkA1tYpr55ftgIQJ2hQFClo5USJc+g 0Yh/0VvUjtVI7eBFeK0V2GI6fLlkEFY935Zu6D+J46bixRhQW9iCz3cGPEWu0Ufsa+Mh gWXSAKrh46PNK2uM1lIe04OhIfO6bDvDWP7RbKgEwVj2J9ADvXkavBQhcJJ9qF9rh3wm 7oFQ== X-Forwarded-Encrypted: i=1; AJvYcCXvmOefYz5+AuocR2/EUMzWddSdEBUmcY95SlzjhCjI9V8sZMO1fQetn06IVpSH810DFEgXBwgz5w==@kvack.org X-Gm-Message-State: AOJu0Yz+uLz6hgUrZ158hSoxFeko2hbNXJC2K4LCgYpD8Lk7zr+ToAVl 7T94o7ek3rFujEB9Pl2D7r49OR9iOvRUiEL9tALYDbsleH3sczip9c1bWiA5jvLw90Q4k8wKLFX 2g+d6cb4g4oIVVmzrMoLvI35Nelzug1DU/DoW X-Gm-Gg: ASbGnctPldHB6rsBpR13ptIfh/d1/aPzTwRR3bNzgS7d/t2Tf19RhdGZIBVLN5vCSSg N/9iNUkvvFEl2u/33a6cCd8QzaNx8FwIdS0BJfw6GlLv45uu1hdiyn7zne37o3Qp0eUlD X-Google-Smtp-Source: AGHT+IEXKag0CbWWo65PECFp9zBOKgXX8j46u6G/syxddzWrSbifJz5pLGcORVckqKpIk0Pe0HRVWO97xjj85MYlduw= X-Received: by 2002:a5d:6d09:0:b0:385:f7ef:a57f with SMTP id ffacd0b85a97d-38a872ec061mr22048811f8f.27.1736862137444; Tue, 14 Jan 2025 05:42:17 -0800 (PST) MIME-Version: 1.0 References: <87frlsbekc.fsf@kernel.org> <18bc911a-ede5-410b-9955-5382bcef975c@lucifer.local> <87msg09uzu.fsf@kernel.org> <8b803030-0ca3-4591-b2f3-bb9bcc2aca21@lucifer.local> <871pxcgg02.fsf@kernel.org> <195559a2-8c5e-40f7-b60a-8534dc177d9b@lucifer.local> In-Reply-To: <195559a2-8c5e-40f7-b60a-8534dc177d9b@lucifer.local> From: Alice Ryhl Date: Tue, 14 Jan 2025 14:42:05 +0100 X-Gm-Features: AbW1kvbF7ASl_7msP-pHOLWL0YVGMPRbRGoz5UT5c8CCAXYl1MdlS1hozZ1UtQU Message-ID: Subject: Re: [PATCH v11 2/8] mm: rust: add vm_area_struct methods that require read access To: Lorenzo Stoakes Cc: Andreas Hindborg , Miguel Ojeda , Matthew Wilcox , 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 , 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: 173C240006 X-Rspamd-Server: rspam12 X-Stat-Signature: 9sf8ctn58f1e5innauij5x1dk7iky96n X-Rspam-User: X-HE-Tag: 1736862138-202570 X-HE-Meta: U2FsdGVkX1/SlYYtcXQsKz8/4dCGFcN6vaaSt/4FbrNak1VpVyhsHcmbDJQs4ReZ/d4+Qlr82yk03qJJED7JtQZpgEViO/1Y/5VROO8AeV3nU7gzBG7MhUkl1A7MNXQZrojrIfYAtUucZs9SoNCAqtWifa1nyZe4sS363nHJZsH2b6uH4b5Z1SQ2Ble/PHxVemDlLhHfqDBhIoqtwaa/JTcFq2NkymxFY0mRsFWc1XshKftEhm2WhBN3KG2jnOdX0vmGz3bloH4R0L6Q6Yima0mxxc3RRQbzYTHoIwWEiysM7h9XVC/qQ0/qR+cjfa2h4Ce2Og0DnOoHb76HKDVGdALxzzfWGTnmSO+G7mt8ogy+ToxJXklhbvm4Nq8nu95KWf7hu0+j9jpe3LFUpdDvphM/jlPZ2BU94lucaKhEhlYSBknM16U9a1HzzTwqyllqktHC7wwrwrNWKZCkQgEDnGT+g7TCTghB2hnvOaU5JzIbUUAAiaqjhIjyWF4YGowu74xe1D3AJrpnNhepWqdnecNDBU/w8+b6TDTwI/wLtKLMrbjpqdyXHAa9I70royIEG+sy+FYeJAjnrVgLgK3+IlMsYzhFOjmv+ebbNC4NFww1/jaYd6nYFW3JfVNVF6g28fMNOdW7XHu62y7ljmRLKkFKNpHL+PjRVGeSyNYPn3Fs4dNYSaTXPXbR9ptY5vciVd5XGZYf0WKKTXubAbRpNQaQwMT1Dzxa9liuWw9W53UeyLu5Zgp1jcCOv/VF6NnzhprbG59lSMIXF5EFCJSnV4WROb5cy1iEBjv1fj04nqzdjJkdg+uEN9W0WHGebRFbjUzhbP7C16I+2fiYxIyxF25M6m2wk/YSX3sqLxZdzlV0r6k4Q3Po2nVaXyuBjczKcHlk+6TRy3fJJ7VTW7KatdfVBWcI02WJCzMm4JL0xW+u3bdIUzC5q+vw1r8NbPm0eub8dQePe07a53STTrM 3N2kE71C VHYFDNTBXPy/H/uOHhke2Hp5+VdRn5a5RkGYFGl+et1kTwc4bAsuuN2W7XR81DrBp4tqD+ssHC89XR6s+ObFMv6/u9uUShT12fglgzJN1XFxM/ApiGMFCYfawWOlN6KHEe6GFrQRBNQksFNGh05+xj25oC4ghFjUqE4FyoheZ8mP2QtrNSyw0TvRfP7/rGY0UXhsCYW71iwxejOZR8cy3VKnCATsB2vjcsrtr/sP9WmXJBFHaXeVBQjwcW+mUNfi99bStKIOWLnVkUbxCPTG0/uUdBHRA9uNJAixXfqP8frtx+mTy6gCsgAzE9obNjkEE9RAH4G06cDyKayQEPfmhrEJIPDf+ygLF9yYRABYhsZK9sBQUhs+pYlwwqsftUjiH4V1H X-Bogosity: Unsure, tests=bogofilter, spamicity=0.499920, 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 Tue, Jan 14, 2025 at 12:57=E2=80=AFPM Lorenzo Stoakes wrote: > > On Tue, Jan 14, 2025 at 10:50:01AM +0100, Alice Ryhl wrote: > > On Mon, Jan 13, 2025 at 3:45=E2=80=AFPM Lorenzo Stoakes > > wrote: > > > > >> > For a series at v11 where there is broad agreement with mainta= iners within > > > > >> > the subsystem which it wraps, perhaps the priority should be t= o try to have > > > > >> > the series merged unless there is significant technical object= ion from the > > > > >> > rust side? > > > > >> > > > > > >> >> > > > > >> >> How about this: > > > > >> >> > > > > >> >> This clears the virtual memory map for the range given by `st= art` and > > > > >> >> `size`, dropping refcounts to memory held by the mappings in = this range. That > > > > >> >> is, anonymous memory is completely freed, file-backed memory = has its > > > > >> >> reference count on page cache folio's dropped, any dirty data= will still > > > > >> >> be written back to disk as usual. > > > > >> > > > > > >> > Sorry I object to this, 'clears the virtual memory map' is rea= lly > > > > >> > vague. What is already there is better. > > > > >> > > > > >> Would you like the proposed paragraph if we replaced "virtual me= mory > > > > >> map" with "page table mappings", or do you object to the entiret= y of the > > > > >> new suggestion? > > > > > > > > > > I object to the suggestion in general. The description is fine as= it is. > > > > > > > > Ok. I'm raising a flag because I had more questions after reading t= he > > > > docstring than before. > > > > > > Sure and so I think this is valuable information, and indicates it's > > > probably worthwhile adding a little extra information on mentioning p= age > > > tables. > > > > Sorry, I'm a bit lost. What would you like me to add? Perhaps there's > > an existing file in Documentation/ that I can link to? > > Sure no problem, I propose expanding: > > /// This clears page table mappings for the range at the leaf level, leav= ing all other page > /// tables intact, > /// anonymous memory is completely freed, file-backed memory has its refe= rence count on page > /// cache folio's dropped, any dirty data will still be written back to d= isk as usual. > > To include information on page tables. I suggest something like: > > /// It may seem odd that we clear at the leaf level, this is however a pr= oduct > /// of the page table structure used to map physical memory into a virtua= l > /// address space - each virtual address actually consists of a bitmap of= array > /// indices into page tables, which form a hierarchical page table level > /// structure. > /// > /// As a result, each page table level maps a multiple of page table leve= ls > /// below, and thus span ever increasing ranges of pages. At the leaf or = PTE > /// level, we map the actual physical memory. > /// > /// It is here where a zap operates, as it the only place we can be certa= in of > /// clearing without impacting any other virtual mappings. It is an > /// implementation detail as to whether the kernel goes further in freein= g > /// unused page tables, but for the purposes of this operation we must on= ly > /// assume that the leaf level is cleared. > > Alice, Andreas - please let me know if this makes sense/is clear or needs > further clarification. That looks reasonable to me. Thanks! Do you have thoughts on the wordings I proposed here? https://lore.kernel.org/all/CAH5fLginc=3DuNPVp1-T-oBrgtE1oi_cBMd65sPkDgqSDj= H_CNfA@mail.gmail.com/ Alice