Message-ID: <507d24e0-4563-4b33-864c-cd1a499fe517@kernel.org>
Date: Thu, 5 Feb 2026 13:03:35 +0100
From: "David Hildenbrand (arm)" <david@...nel.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
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 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.

Fun.


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

-- 
Cheers,

David

Powered by blists - more mailing lists