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 3CA74C02183 for ; Wed, 15 Jan 2025 11:03:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id ACD156B0083; Wed, 15 Jan 2025 06:03:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A7CC06B0085; Wed, 15 Jan 2025 06:03:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 944816B0088; Wed, 15 Jan 2025 06:03:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 770726B0083 for ; Wed, 15 Jan 2025 06:03:45 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id E79F6161180 for ; Wed, 15 Jan 2025 11:03:44 +0000 (UTC) X-FDA: 83009400768.16.440C9CF Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf10.hostedemail.com (Postfix) with ESMTP id 46E62C0006 for ; Wed, 15 Jan 2025 11:03:43 +0000 (UTC) Authentication-Results: imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JMYT7ldS; spf=pass (imf10.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=1736939023; 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=bZF9qYZjTl2qAZfueZxY25UdxHzQzc1tBlZt6AOUrKw=; b=yL5X+Ux0HLp0BVFW0Dw7D5BUmooSgtd1ZU5H2NI0nDZdfGZrJ/AERNbeT6IbhcH0bQ5bNe ktDF/Jx2dsqd68tv+ZKh7ZQ6ms16ffD23WD3QIilqAQh2uQnK2ELDXrOFM3YNEgVAV3F05 F9WuivJyFuWvNU6ZfTpxu8jHJ07VKx8= ARC-Authentication-Results: i=1; imf10.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JMYT7ldS; spf=pass (imf10.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-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1736939023; a=rsa-sha256; cv=none; b=yn3TzP2aLGMmrxCbwubACwxyDzpoF4hgu4tWBmSrwaf/SIBPDMoM0b2nlrVNg1Q21WeUpR WksLh6QoLXh+EieP+Sx8yRSZH4LdnNsRmK/V2gRzVGzUFXIVn0a7hQwXXVRLZLP/68f+XX Waihdu3wpg9CJUxprbPHJkMxSy8PEWk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 7211AA41C19; Wed, 15 Jan 2025 11:01:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3BA57C4CEDF; Wed, 15 Jan 2025 11:03:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1736939022; bh=bZF9qYZjTl2qAZfueZxY25UdxHzQzc1tBlZt6AOUrKw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=JMYT7ldScx4SnmhBtVbPoHO/pcHEHtTyIrh3477NpQPk0BEwAK0UJxHIo+KxflQWC qkHQ3XIJolOkU25tLDoF340aTnYHlIgDRq7DQmRCdyxXOahYniSpsFA96RVUvCy0gL u606RIVVGdvyqkmJ0L1dEqqCvubkQ88DwIJ6rLE3pxez/Ha44FsY5jUtU/RfXXV/vm Es8kVZ8TCpoNICndnQBysEGI9iTwO/OehJuk0ftL/BuS2KNyDy7uOQgBy+eJ5a1PW7 AKaaqV1a1fqr01ufAdHMWwa2n8CvQ2YvwdCHEw5qOvQidBaeRaA91CrMmTmFLwmyLM F2LBBhtCLiCFQ== From: Andreas Hindborg To: "Lorenzo Stoakes" Cc: "Alice Ryhl" , "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" , , , Subject: Re: [PATCH v11 2/8] mm: rust: add vm_area_struct methods that require read access In-Reply-To: <195559a2-8c5e-40f7-b60a-8534dc177d9b@lucifer.local> (Lorenzo Stoakes's message of "Tue, 14 Jan 2025 11:57:23 +0000") 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> User-Agent: mu4e 1.12.7; emacs 29.4 Date: Wed, 15 Jan 2025 12:02:14 +0100 Message-ID: <874j20e3wp.fsf@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 46E62C0006 X-Stat-Signature: u7qfab1rujx3c9tbpzbw7rihbscnc917 X-Rspam-User: X-Rspamd-Server: rspam11 X-HE-Tag: 1736939023-794798 X-HE-Meta: U2FsdGVkX18ufjeRsPPS0AmmntOCwnMm6UBr1BfNM9NKt7svJGUe6iBeuRuA8/zA4eYsLXw/BMnk1Nkwt5eB3UrryEKxoAoPm9cqap4UxB7gDIPIQmTP74vRpiEd7EpAk+mfe2C8LtdA+whkMBFRLN2YaLc4efvA4SrtLPTxdRaQg+biqND6uiB6Y5IVMs+l9rCfxTRw/rz8EbdmGjDN4JRXSxqtE0Vv2KxWhBcmgKjisy17ZChIfD2ZpXrNYsvnWdBDT7whrGVIYCHG0wF7AoKHYI9dPJBmAgDCr/eelxHlPZJdWAKz+eMCvVi1cGdhwHZKDILEsq1ZhRePGd3OglCxjjAo6s559SbK7QzwbpGFSFw17X1BCVnAKSj7Ur+sszXmGnoYMHFopEkDnSVNxHXNW24YHhDG2WmDomoZEuoMgNR5Q/ZcJtPQf8MXUv7vdUB/IbQFlv5ZWe49KR8kZOdKtvfvkL1RacMYi83vlcoWqDaREEoxJehYybxHF9vNYmYXnGqSP7x6So2Vg8Jj4fmxYkgWzpZwzd3KF1QjLI4sqp+1vGdohm7BM67JOCXCtvNlFnms8QTvdzLMfr+7ti0KBQX+8SKaRkPV7oMWm6ROoppYOp1xbqhlJ9WC3erOEyF9XlE1UVJOMF5ix+Z1oqQ54NI1JJLN5J0mNqaL/tSj9Kq/WfBHuTrkY1jvalpih9XoM8X2w/jSnaswjOTw2719ZDyYo9hW/fft13i8k8vgYXR/61Duy5lYrCL3D65Uaj3duLSVn/8KtwMGVmM8J43fIr7cINI81PYyKhFV7cbt2oO4RCovDb3ZO20wxNAnMNVKUUPeniKMtz2TpOYcH9uGu+y2lt1EV0uCrUK00MzncRj2nGnoLkQdU2SPpRF8jZMiAX+qmrSPhyUd/gYPZqP/rtPeJGeNmBKDxn/6U5V+YV4g3lkBC+cOh9TJ3ykM3CgM73xozkZxAxZoOe/ o8+vZSl7 Cs/d/0mldztJoWRC58SGD2N4gBWLiR6aXEhs+/THArDYKMG90cJ+kFwDawYbjPnm1U15Kj4U9SBQ0xqBZNdRsPKTTUosvEmYpxI3JiFaz9IDPvibINlrWLkmEjiUZYGWtFmdu+29rbqv49p6a/ZhwNKYSDRbt/QamNTAA5tSwMHPAq065Yoq9PNHrXrd18Bu7RMnk+h2RzHSC00p4xFkuFgIvATJ39v6aeE+7a3RKtRrQHFKjageOXTNSAelqkaehpFrJKkS+F7ZCjJJjxN6WmIY7jS8LeeA89/wbNuglV1R2U2+xOutLm85PcqCO9PE1a2RzVIhalcp53H7SHbe1fxcZc97CIoewJABkK2i8Hij/MvE= X-Bogosity: Ham, tests=bogofilter, spamicity=0.423904, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: "Lorenzo Stoakes" writes: > 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 maintai= ners within >> > > >> > the subsystem which it wraps, perhaps the priority should be to= try to have >> > > >> > the series merged unless there is significant technical objecti= on from the >> > > >> > rust side? >> > > >> > >> > > >> >> >> > > >> >> How about this: >> > > >> >> >> > > >> >> This clears the virtual memory map for the range given by `sta= rt` and >> > > >> >> `size`, dropping refcounts to memory held by the mappings in t= his range. That >> > > >> >> is, anonymous memory is completely freed, file-backed memory h= as 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 real= ly >> > > >> > vague. What is already there is better. >> > > >> >> > > >> Would you like the proposed paragraph if we replaced "virtual mem= ory >> > > >> map" with "page table mappings", or do you object to the entirety= 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 the >> > > 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 pa= ge >> > 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 virtual > /// 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 freeing > /// 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. Sounds good to me - thanks. @Alice - can we add PTE, PTE entry, PMD, PUD to the vocabulary at the top? Not sure if it should go here in virt.rs or in mm.rs. If you have no cycles I can try to add it down the road. Best regards, Andreas Hindborg