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: <18bc911a-ede5-410b-9955-5382bcef975c@lucifer.local>
Date: Thu, 9 Jan 2025 08:19:53 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Andreas Hindborg <a.hindborg@...nel.org>
Cc: Alice Ryhl <aliceryhl@...gle.com>, Miguel Ojeda <ojeda@...nel.org>,
        Matthew Wilcox <willy@...radead.org>, 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

On Thu, Jan 09, 2025 at 09:02:11AM +0100, Andreas Hindborg wrote:
> "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?

I don't understand your objection. The whole nature of a zap is to traverse
leaf level page table mappings, clearing the entries, leaving the other
page table entries intact.

That is, precisely what is written here. In fact I think this
characterisation is derived from discussions had with us in mm, and it is
one with which I am happy.

Why is it problematic to accurately describe what this does?

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.

>
> >
> >> > 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
>
>

Let's please get this series merged. I think Alice has demonstrated
remarkable patience already, and modulo significant technical pushback on
the rust side (on which I defer entirely to the expertise of rust people),
I want to see this go in.