linux-kernel - Re: [PATCH 3/5] mm: export zap_page_range_single and list_lru

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: <a0894efd-bb67-4ec9-9801-4c52b381396c@lucifer.local>
Date: Thu, 5 Feb 2026 12:12:15 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: "David Hildenbrand (arm)" <david@...nel.org>
Cc: Alice Ryhl <aliceryhl@...gle.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Carlos Llamas <cmllamas@...gle.com>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
        Paul Moore <paul@...l-moore.com>, James Morris <jmorris@...ei.org>,
        "Serge E. Hallyn" <serge@...lyn.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Dave Chinner <david@...morbit.com>,
        Qi Zheng <zhengqi.arch@...edance.com>,
        Roman Gushchin <roman.gushchin@...ux.dev>,
        Muchun Song <muchun.song@...ux.dev>,
        "Liam R. Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
        Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
        Miguel Ojeda <ojeda@...nel.org>, Boqun Feng <boqun.feng@...il.com>,
        Gary Guo <gary@...yguo.net>,
        Björn Roy Baron <bjorn3_gh@...tonmail.com>,
        Benno Lossin <lossin@...nel.org>,
        Andreas Hindborg <a.hindborg@...nel.org>,
        Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>,
        kernel-team@...roid.com, linux-fsdevel@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-security-module@...r.kernel.org,
        linux-mm@...ck.org, rust-for-linux@...r.kernel.org,
        Christoph Hellwig <hch@...radead.org>
Subject: Re: [PATCH 3/5] mm: export zap_page_range_single and list_lru_add/del

On Thu, Feb 05, 2026 at 01:03:35PM +0100, David Hildenbrand (arm) wrote:
> On 2/5/26 12:57, Lorenzo Stoakes wrote:
> > +cc Christoph for his input on exports here.
> >
> > On Thu, Feb 05, 2026 at 12:43:03PM +0100, David Hildenbrand (arm) wrote:
> > > On 2/5/26 12:29, Lorenzo Stoakes wrote:
> > > >
> > > > Same point as before about exporting symbols, but given the _obj variants are
> > > > exported already this one is more valid.
> > > >
> > > >
> > > > Sorry but I don't want this exported at all.
> > > >
> > > > This is an internal implementation detail which allows fine-grained control of
> > > > behaviour via struct zap_details (which binder doesn't use, of course :)
> > >
> > > I don't expect anybody to set zap_details, but yeah, it could be abused.
> > > It could be abused right now from anywhere else in the kernel
> > > where we don't build as a module :)
> > >
> > > Apparently we export a similar function in rust where we just removed the last parameter.
> >
> > What??
> >
> > Alice - can you confirm rust isn't exporting stuff that isn't explicitly marked
> > EXPORT_SYMBOL*() for use by other rust modules?
> >
> > It's important we keep this in sync, otherwise rust is overriding kernel policy.
> >
> > >
> > > I think zap_page_range_single() is only called with non-NULL from mm/memory.c.
> > >
> > > So the following makes likely sense even outside of the context of this series:
> > >
> >
> > Yeah this looks good so feel free to add a R-b from me tag when you send it
> > BUT...
> >
> > I'm still _very_ uncomfortable with exporting this just for binder which seems
> > to be doing effectively mm tasks itself in a way that makes me think it needs a
> > rework to not be doing that and to update core mm to add functionality if it's
> > needed.
> >
> > In any case, if we _do_ export this I think I'm going to insist on this being
> > EXPORT_SYMBOL_FOR_MODULES() _only_ for the binder in-tree module.
>
> Works for me.

:)

>
> Staring at it again, I think I landed in cleanup land.
>
> zap_vma_ptes() is exported and does the same thing as
> zap_page_range_single(), just with some additional safety checks.

Yeah saw that, except it insists only on VM_PFN VMAs which makes me question our
making this more generally available to OOT drivers.

>
> Fun.
>
>
> Let me cleanup. Good finger exercise after one month of almost-not coding :)

:) I am less interested in cleanups at this stage at least for a while so feel
free to fixup glaringly horrible things so I can vicariously enjoy it at
least...

>
> --
> Cheers,
>
> David

Cheers, Lorenzo