linux-kernel - Re: [PATCH v11 2/8] mm: rust: add vm_area_struct methods that require read access

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87frlsbekc.fsf@kernel.org>
Date: Thu, 09 Jan 2025 09:02:11 +0100
From: Andreas Hindborg <a.hindborg@...nel.org>
To: "Alice Ryhl" <aliceryhl@...gle.com>
Cc: "Miguel Ojeda" <ojeda@...nel.org>,  "Matthew Wilcox"
 <willy@...radead.org>,  "Lorenzo Stoakes" <lorenzo.stoakes@...cle.com>,
  "Vlastimil Babka" <vbabka@...e.cz>,  "John Hubbard"
 <jhubbard@...dia.com>,  "Liam R. Howlett" <Liam.Howlett@...cle.com>,
  "Andrew Morton" <akpm@...ux-foundation.org>,  "Greg Kroah-Hartman"
 <gregkh@...uxfoundation.org>,  "Arnd Bergmann" <arnd@...db.de>,
  "Christian Brauner" <brauner@...nel.org>,  "Jann Horn"
 <jannh@...gle.com>,  "Suren Baghdasaryan" <surenb@...gle.com>,  "Alex
 Gaynor" <alex.gaynor@...il.com>,  "Boqun Feng" <boqun.feng@...il.com>,
  "Gary Guo" <gary@...yguo.net>,  Björn Roy Baron
 <bjorn3_gh@...tonmail.com>,  "Benno Lossin" <benno.lossin@...ton.me>,
  "Trevor Gross" <tmgross@...ch.edu>,  <linux-kernel@...r.kernel.org>,
  <linux-mm@...ck.org>,  <rust-for-linux@...r.kernel.org>
Subject: Re: [PATCH v11 2/8] mm: rust: add vm_area_struct methods that
 require read access

"Alice Ryhl" <aliceryhl@...gle.com> writes:

> On Mon, Dec 16, 2024 at 3:51 PM Andreas Hindborg <a.hindborg@...nel.org> wrote:
>>
>>
>> > +
>> > +    /// Zap pages in the given page range.
>> > +    ///
>> > +    /// This clears page table mappings for the range at the leaf level, leaving all other page
>> > +    /// tables intact,
>>
>> I don't fully understand this docstring. Is it correct that the function
>> will unmap the address range given by `start` and `size`, _and_ free the
>> pages used to hold the mappings at the leaf level of the page table?
>
> If the vma owns a refcount on those pages, then the refcounts are dropped.

Maybe drop the "at the leaf level leaving all other page tables intact".
It confuses me, since when would this not be the case?

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.

>
>> > and freeing any memory referenced by the VMA 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.
>> > +    #[inline]
>> > +    pub fn zap_page_range_single(&self, address: usize, size: usize) {

Best regards,
Andreas Hindborg