linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Andreas Hindborg <a.hindborg@kernel.org>
To: "Lorenzo Stoakes" <lorenzo.stoakes@oracle.com>
Cc: "Alice Ryhl" <aliceryhl@google.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Matthew Wilcox" <willy@infradead.org>,
	"Vlastimil Babka" <vbabka@suse.cz>,
	"John Hubbard" <jhubbard@nvidia.com>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Christian Brauner" <brauner@kernel.org>,
	"Jann Horn" <jannh@google.com>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Alex Gaynor" <alex.gaynor@gmail.com>,
	"Boqun Feng" <boqun.feng@gmail.com>,
	"Gary Guo" <gary@garyguo.net>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <benno.lossin@proton.me>,
	"Trevor Gross" <tmgross@umich.edu>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	rust-for-linux@vger.kernel.org
Subject: Re: [PATCH v11 2/8] mm: rust: add vm_area_struct methods that require read access
Date: Wed, 15 Jan 2025 12:02:14 +0100	[thread overview]
Message-ID: <874j20e3wp.fsf@kernel.org> (raw)
In-Reply-To: <195559a2-8c5e-40f7-b60a-8534dc177d9b@lucifer.local> (Lorenzo Stoakes's message of "Tue, 14 Jan 2025 11:57:23 +0000")

"Lorenzo Stoakes" <lorenzo.stoakes@oracle.com> writes:

> On Tue, Jan 14, 2025 at 10:50:01AM +0100, Alice Ryhl wrote:
>> On Mon, Jan 13, 2025 at 3:45 PM Lorenzo Stoakes
>> <lorenzo.stoakes@oracle.com> wrote:
>> > > >> > For a series at v11 where there is broad agreement with maintainers within
>> > > >> > the subsystem which it wraps, perhaps the priority should be to try to have
>> > > >> > the series merged unless there is significant technical objection from the
>> > > >> > rust side?
>> > > >> >
>> > > >> >>
>> > > >> >> How about this:
>> > > >> >>
>> > > >> >> This clears the virtual memory map for the range given by `start` 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 really
>> > > >> > vague. What is already there is better.
>> > > >>
>> > > >> Would you like the proposed paragraph if we replaced "virtual memory
>> > > >> 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 page
>> > 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, leaving all other page
> /// tables intact,
> /// 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.
>
> 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 product
> /// 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 levels
> /// 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 certain 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 only
> /// 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





  parent reply	other threads:[~2025-01-15 11:03 UTC|newest]

Thread overview: 65+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <nGnC07PmUqofHiX7HfZAOCIK1-CPS7DF8kdGhDgJgPts5KYrCrimmovP-4YMVgI7WRmFnGwbdndTtxCfp278cg==@protonmail.internalid>
2024-12-11 10:37 ` [PATCH v11 0/8] Rust support for mm_struct, vm_area_struct, and mmap Alice Ryhl
2024-12-11 10:37   ` [PATCH v11 1/8] mm: rust: add abstraction for struct mm_struct Alice Ryhl
2024-12-16 11:31     ` Andreas Hindborg
2025-01-13  9:53       ` Alice Ryhl
2025-01-14 15:48         ` Lorenzo Stoakes
2025-01-15  1:54           ` John Hubbard
2025-01-15 12:13             ` Lorenzo Stoakes
2025-01-15 10:36         ` Andreas Hindborg
2025-01-15 20:20           ` John Hubbard
2025-01-17  0:45     ` Balbir Singh
2025-01-17 12:47       ` Alice Ryhl
2024-12-11 10:37   ` [PATCH v11 2/8] mm: rust: add vm_area_struct methods that require read access Alice Ryhl
2024-12-16 12:12     ` Andreas Hindborg
2025-01-08 12:21       ` Alice Ryhl
2025-01-09  8:02         ` Andreas Hindborg
2025-01-09  8:19           ` Lorenzo Stoakes
2025-01-09  9:50             ` Andreas Hindborg
2025-01-09 11:29               ` Lorenzo Stoakes
2025-01-09 15:32                 ` Andreas Hindborg
2025-01-13 14:45                   ` Lorenzo Stoakes
2025-01-14  9:50                     ` Alice Ryhl
2025-01-14 11:57                       ` Lorenzo Stoakes
2025-01-14 13:42                         ` Alice Ryhl
2025-01-14 15:33                           ` Lorenzo Stoakes
2025-01-15 11:02                         ` Andreas Hindborg [this message]
2025-01-15 11:04                           ` Alice Ryhl
2024-12-11 10:37   ` [PATCH v11 3/8] mm: rust: add vm_insert_page Alice Ryhl
2024-12-16 12:25     ` Andreas Hindborg
2025-01-13 10:02       ` Alice Ryhl
2025-01-15  9:33         ` Andreas Hindborg
2024-12-11 10:37   ` [PATCH v11 4/8] mm: rust: add lock_vma_under_rcu Alice Ryhl
2024-12-16 12:47     ` Andreas Hindborg
2025-01-13 10:04       ` Alice Ryhl
2025-01-15  9:34         ` Andreas Hindborg
2024-12-11 10:37   ` [PATCH v11 5/8] mm: rust: add mmput_async support Alice Ryhl
2024-12-16 13:10     ` Andreas Hindborg
2024-12-11 10:37   ` [PATCH v11 6/8] mm: rust: add VmAreaNew for f_ops->mmap() Alice Ryhl
2024-12-16 13:41     ` Andreas Hindborg
2025-01-08 12:23       ` Alice Ryhl
2025-01-09  8:19         ` Andreas Hindborg
2025-01-13 10:17           ` Alice Ryhl
2025-01-15  9:57             ` Andreas Hindborg
2024-12-17  9:31     ` Andreas Hindborg
2025-01-08 12:24       ` Alice Ryhl
2025-01-09  8:23         ` Andreas Hindborg
2025-01-13 10:18           ` Alice Ryhl
2025-01-10 13:34     ` Alice Ryhl
2025-01-10 16:09       ` Lorenzo Stoakes
2024-12-11 10:37   ` [PATCH v11 7/8] rust: miscdevice: add mmap support Alice Ryhl
2024-12-16 13:53     ` Andreas Hindborg
2024-12-11 10:37   ` [PATCH v11 8/8] task: rust: rework how current is accessed Alice Ryhl
2024-12-16 14:47     ` Andreas Hindborg
2025-01-08 12:32       ` Alice Ryhl
2025-01-09  8:42         ` Andreas Hindborg
2025-01-13 10:26           ` Alice Ryhl
2025-01-15 10:24             ` Andreas Hindborg
2024-12-16 23:40     ` Boqun Feng
2025-01-13 10:30       ` Alice Ryhl
2025-01-14 15:30         ` Boqun Feng
2024-12-11 10:47   ` [PATCH v11 0/8] Rust support for mm_struct, vm_area_struct, and mmap Alice Ryhl
2024-12-12 14:47     ` Konstantin Ryabitsev
2024-12-13 14:42       ` Alice Ryhl
2024-12-13 14:47         ` Konstantin Ryabitsev
2024-12-16 11:04   ` Andreas Hindborg
2024-12-16 11:46     ` Alice Ryhl

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=874j20e3wp.fsf@kernel.org \
    --to=a.hindborg@kernel.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=alex.gaynor@gmail.com \
    --cc=aliceryhl@google.com \
    --cc=arnd@arndb.de \
    --cc=benno.lossin@proton.me \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun.feng@gmail.com \
    --cc=brauner@kernel.org \
    --cc=gary@garyguo.net \
    --cc=gregkh@linuxfoundation.org \
    --cc=jannh@google.com \
    --cc=jhubbard@nvidia.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=surenb@google.com \
    --cc=tmgross@umich.edu \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox