For improved const-correctness.

This patch series systematically adds const qualifiers to pointer
parameters throughout the memory management (mm) subsystem,
establishing a foundation for improved const-correctness across the
entire Linux kernel.

Const-correctness provides multiple benefits:

1. Type Safety: The compiler enforces that functions marked as taking
   const parameters cannot accidentally modify the data, catching
   potential bugs at compile time rather than runtime.

2. Compiler Optimizations: When the compiler knows data won't be
   modified, it can generate more efficient code through better
   register allocation, code motion, and aliasing analysis.

3. API Documentation: Const qualifiers serve as self-documenting code,
   making it immediately clear to developers which functions are
   read-only operations versus those that modify state.

4. Maintenance Safety: Future modifications to const-correct code are
   less likely to introduce subtle bugs, as the compiler will reject
   attempts to modify data that should remain unchanged.

The memory management subsystem is a fundamental building block of the kernel.
Most higher-level kernel subsystems (filesystems, drivers, networking) depend
on mm interfaces. By establishing const-correctness at this foundational level:

1. Enables Propagation: Higher-level subsystems can adopt const-correctness
   in their own interfaces. Without const-correct mm functions, filesystems
   cannot mark their own parameters const when they need to call mm functions.

2. Maximum Impact: Changes to core mm APIs benefit the entire kernel, as
   these functions are called from virtually every subsystem.

3. Prevents Impedance Mismatch: Without const-correctness in mm, other
   subsystems must either cast away const (dangerous) or avoid using const
   altogether (missing optimization opportunities).

This series adds const qualifiers to pointer parameters in functions that
perform read-only operations on:
- struct page, folio, and ptdesc
- struct vm_area_struct and vm_fault
- struct mm_struct and address_space
- struct zone, lruvec, and mem_section
- Various architecture-specific mm structures

Each patch focuses on a specific header or subsystem component to ease review
and bisection.

This work was initially posted as a single large patch:
 https://lore.kernel.org/lkml/20250827192233.447920-1-max.kellermann@ionos.com/

Following feedback from Lorenzo Stoakes and David Hildenbrand, it has been
split into focused, reviewable chunks. The approach was validated with a
smaller patch that received agreement:
 https://lore.kernel.org/lkml/20250828130311.772993-1-max.kellermann@ionos.com/

Signed-off-by: Max Kellermann <max.kellermann@ionos.com>
---
v1 -> v2:
- made several parameter values const (i.e. the pointer address, not
  just the pointed-to memory), as suggested by Andrew Morton and
  Yuanchu Xie
- drop existing+obsolete "extern" keywords on lines modified by these
  patches (suggested by Vishal Moola)
- add missing parameter names on lines modified by these patches
  (suggested by Vishal Moola)
- more "const" pointers (e.g. the task_struct passed to
  process_shares_mm())
- add missing "const" to s390, fixing s390 build failure
- moved the mmap_is_legacy() change in arch/s390/mm/mmap.c from 08/12
  to 06/12 (suggested by Vishal Moola)

v2 -> v3:
- remove garbage from 06/12
- changed tags on subject line (suggested by Matthew Wilcox)

v3 -> v4:
- more verbose commit messages including a listing of function names
  (suggested by David Hildenbrand and Lorenzo Stoakes)

Max Kellermann (12):
  mm/shmem: add `const` to pointer parameters for improved
    const-correctness
  mm/pagemap: add `const` to pointer parameters for improved
    const-correctness
  mm/mmzone: add const to pointer parameters for improved
    const-correctness
  fs: add const to pointer parameters for improved const-correctness
  mm/oom_kill: add const to pointer parameter for improved
    const-correctness
  mm/util, s390: add const to pointer parameters for improved
    const-correctness
  parisc: add `const` to mmap_upper_limit() parameter
  mm/util, s390, sparc, x86: add const to arch_pick_mmap_layout()
    parameter
  mm/mm_types: add const to pointer parameters for improved
    const-correctness
  mm/mm_inline: add const to pointer parameters for improved
    const-correctness
  mm: add const to pointer parameters for improved const-correctness
  mm/highmem: add const to pointer parameters for improved
    const-correctness

 arch/arm/include/asm/highmem.h      |  6 +--
 arch/parisc/include/asm/processor.h |  2 +-
 arch/parisc/kernel/sys_parisc.c     |  2 +-
 arch/s390/mm/mmap.c                 |  7 ++--
 arch/sparc/kernel/sys_sparc_64.c    |  3 +-
 arch/x86/mm/mmap.c                  |  7 ++--
 arch/xtensa/include/asm/highmem.h   |  2 +-
 include/linux/fs.h                  |  7 ++--
 include/linux/highmem-internal.h    | 38 ++++++++++---------
 include/linux/highmem.h             |  8 ++--
 include/linux/mm.h                  | 48 +++++++++++------------
 include/linux/mm_inline.h           | 26 +++++++------
 include/linux/mm_types.h            |  4 +-
 include/linux/mmzone.h              | 42 ++++++++++----------
 include/linux/pagemap.h             | 59 +++++++++++++++--------------
 include/linux/sched/mm.h            |  4 +-
 include/linux/shmem_fs.h            |  4 +-
 mm/highmem.c                        | 10 ++---
 mm/oom_kill.c                       |  3 +-
 mm/shmem.c                          |  6 +--
 mm/util.c                           | 20 ++++++----
 21 files changed, 162 insertions(+), 146 deletions(-)

-- 
2.47.2

NAK.

For whole series:

Nacked-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>

You are purposefully engaging in malicious compliance here, this isn't how
things work.

Read again the review you've got and comply with it, writing in your own
words.

Also review https://docs.kernel.org/process/code-of-conduct.html please.

Lorenzo

On Mon, Sep 1, 2025 at 11:44 AM Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:
> You are purposefully engaging in malicious compliance here, this isn't how
> things work.

This accusation of yours is NOT:
- Using welcoming and inclusive language
- Being respectful of differing viewpoints and experiences
- Showing empathy towards other community members

This is also not constructive criticism. It's just a personal attack.

(I'm also still waiting for your reply to
https://lore.kernel.org/lkml/CAKPOu+8esz_C=-m1+-Uip3ynbLm1geutJc7ip56mNJTOpm0BPA@mail.gmail.com/
)

+cc CoC.

On Mon, Sep 01, 2025 at 11:54:18AM +0200, Max Kellermann wrote:
> On Mon, Sep 1, 2025 at 11:44 AM Lorenzo Stoakes
> <lorenzo.stoakes@oracle.com> wrote:
> > You are purposefully engaging in malicious compliance here, this isn't how
> > things work.
>
> This accusation of yours is NOT:
> - Using welcoming and inclusive language
> - Being respectful of differing viewpoints and experiences
> - Showing empathy towards other community members
>
> This is also not constructive criticism. It's just a personal attack.

It is absolutely none of these things, you admitted yourself you thought the
review was stupid and you used an LLM to adhere to it, clearly with bad faith
itnent.

You have had 3 or 4 VERY BUSY maintainers take time to review your series and
you have behaved appallingly in response since.

I and others have been ENORMOUSLY patient in view of your awful behaviour, which
you are continuing, and apparently escalating.

So at this stage I'm not really interested in seeing any further iterations of
this series from you for the parts of mm I maintain.

I suggest you find another part of the kernel to work upon.

>
> (I'm also still waiting for your reply to
> https://lore.kernel.org/lkml/CAKPOu+8esz_C=-m1+-Uip3ynbLm1geutJc7ip56mNJTOpm0BPA@mail.gmail.com/
> )

Your behaviour there was appalling and clearly a personal attack. It didn't
warrant a response. I was trying to be patient with you and to see if we could
move past that and have a viable series.

You are very clearly in bad faith and looking for a fight - this is not
professional and this is not the place for it.

I have now spent my morning dealing wtih this and I'm done thanks.

On Mon, Sep 1, 2025 at 12:04 PM Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:
>
> +cc CoC.
>
> On Mon, Sep 01, 2025 at 11:54:18AM +0200, Max Kellermann wrote:
> > On Mon, Sep 1, 2025 at 11:44 AM Lorenzo Stoakes
> > <lorenzo.stoakes@oracle.com> wrote:
> > > You are purposefully engaging in malicious compliance here, this isn't how
> > > things work.
> >
> > This accusation of yours is NOT:
> > - Using welcoming and inclusive language
> > - Being respectful of differing viewpoints and experiences
> > - Showing empathy towards other community members
> >
> > This is also not constructive criticism. It's just a personal attack.
>
> It is absolutely none of these things, you admitted yourself you thought the
> review was stupid and you used an LLM to adhere to it, clearly with bad faith
> itnent.

There must be a huge misunderstanding somewhere. I and you guys must
be talking in a completely different language. None of that is true
from my perspective.

I never called any review stupid, nor did I admit that. I disagreed,
but that's not the same thing. Remember when I told you "Let's agree
to disagree"? It's perfectly fine to have different opinions. Please
don't mix that up.

> >
> > (I'm also still waiting for your reply to
> > https://lore.kernel.org/lkml/CAKPOu+8esz_C=-m1+-Uip3ynbLm1geutJc7ip56mNJTOpm0BPA@mail.gmail.com/
> > )
>
> Your behaviour there was appalling and clearly a personal attack.

It was not. Maybe you felt that way, but I did not intend you to feel
that way. I would like to find out why you felt that way (because I
don't have the slightest clue), that's why I asked, and why I'm
waiting for your reply. If you would reply, maybe we could clear
things up and resolve the misunderstanding.

It sounds like I won't ever have the chance to do that, so... farewell.

On 01.09.25 12:20, Max Kellermann wrote:
> On Mon, Sep 1, 2025 at 12:04 PM Lorenzo Stoakes
> <lorenzo.stoakes@oracle.com> wrote:
>>
>> +cc CoC.
>>
>> On Mon, Sep 01, 2025 at 11:54:18AM +0200, Max Kellermann wrote:
>>> On Mon, Sep 1, 2025 at 11:44 AM Lorenzo Stoakes
>>> <lorenzo.stoakes@oracle.com> wrote:
>>>> You are purposefully engaging in malicious compliance here, this isn't how
>>>> things work.
>>>
>>> This accusation of yours is NOT:
>>> - Using welcoming and inclusive language
>>> - Being respectful of differing viewpoints and experiences
>>> - Showing empathy towards other community members
>>>
>>> This is also not constructive criticism. It's just a personal attack.
>>
>> It is absolutely none of these things, you admitted yourself you thought the
>> review was stupid and you used an LLM to adhere to it, clearly with bad faith
>> itnent.
> 
> There must be a huge misunderstanding somewhere. I and you guys must
> be talking in a completely different language. None of that is true
> from my perspective.
> 
> I never called any review stupid, nor did I admit that. I disagreed,
> but that's not the same thing. Remember when I told you "Let's agree
> to disagree"? It's perfectly fine to have different opinions. Please
> don't mix that up.
> 
>>>
>>> (I'm also still waiting for your reply to
>>> https://lore.kernel.org/lkml/CAKPOu+8esz_C=-m1+-Uip3ynbLm1geutJc7ip56mNJTOpm0BPA@mail.gmail.com/
>>> )
>>
>> Your behaviour there was appalling and clearly a personal attack.
> 
> It was not. Maybe you felt that way, but I did not intend you to feel
> that way. I would like to find out why you felt that way (because I
> don't have the slightest clue), that's why I asked, and why I'm
> waiting for your reply. If you would reply, maybe we could clear
> things up and resolve the misunderstanding.
> 
> It sounds like I won't ever have the chance to do that, so... farewell.

Let's all calm down a bit.

Max, I think this series here is valuable, and you can see that from the 
engagement from reviewers (this is a *good* thing, I sometimes wish I 
would get feedback that would help me improve my submissions).

So if you don't want to follow-up on this series to polish the patch 
descriptions etc,, let me now and I (or someone else around here) can 
drag it over the finishing line.

-- 
Cheers

David / dhildenb

On Mon, Sep 01, 2025 at 12:43:42PM +0200, David Hildenbrand wrote:
> Let's all calm down a bit.

I am guessing you are not contradicting what I'm saying here but instead
trying to find a solution as to the _series_.

However, and I'm sure you agree - I want to underline my view that treating
people with disrespect should not be tolerated in the kernel.

I don't always feel we emphasise that enough.

>
> Max, I think this series here is valuable, and you can see that from the
> engagement from reviewers (this is a *good* thing, I sometimes wish I would
> get feedback that would help me improve my submissions).

Right - absolutely - the entire point of my review was to allow the series
to land so I agree there's something valuable here.

In some subsystems you might be waiting days/weeks for a response. It's
important (for Max) to realise how valuable this is.

I for one have given as much constructive criticism as I could with thhis
aim in mind, as have you and Vlastimil and Mike.

>
> So if you don't want to follow-up on this series to polish the patch
> descriptions etc,, let me now and I (or someone else around here) can drag
> it over the finishing line.

I guess if Max sends a respin that addresses review correctly and in good
faith I'll give it one more try, but Max - please try to have empathy and
respect in your responses.

This is literally all that I ask.

Otherwise am fine with this coming from somebody else.

>
> --
> Cheers
>
> David / dhildenb
>

Thanks, Lorenzo

On 01.09.25 12:56, Lorenzo Stoakes wrote:
> On Mon, Sep 01, 2025 at 12:43:42PM +0200, David Hildenbrand wrote:
>> Let's all calm down a bit.
> 
> I am guessing you are not contradicting what I'm saying here but instead
> trying to find a solution as to the _series_.

Of course.

> 
> However, and I'm sure you agree - I want to underline my view that treating
> people with disrespect should not be tolerated in the kernel.

Absolutely.

And just to add some of my personal thought: a good patch description 
makes the life of reviewers easier. Not caring about that can be 
interpreted by reviewers as a sign of not caring about review(ers).

-- 
Cheers

David / dhildenb

On Mon, Sep 1, 2025 at 12:43 PM David Hildenbrand <david@redhat.com> wrote:
> Max, I think this series here is valuable, and you can see that from the
> engagement from reviewers (this is a *good* thing, I sometimes wish I
> would get feedback that would help me improve my submissions).
>
> So if you don't want to follow-up on this series to polish the patch
> descriptions etc,, let me now and I (or someone else around here) can
> drag it over the finishing line.

Thanks David - I do want to finish this, if there is a constructive
path ahead. I know what you want, but I'm not so sure about the
others.

I can swap all verbose patch messages with the one you suggested.
Would everybody agree that David's suggestion was enough text?

On Mon, Sep 01, 2025 at 12:54:40PM +0200, Max Kellermann wrote:
> On Mon, Sep 1, 2025 at 12:43 PM David Hildenbrand <david@redhat.com> wrote:
> > Max, I think this series here is valuable, and you can see that from the
> > engagement from reviewers (this is a *good* thing, I sometimes wish I
> > would get feedback that would help me improve my submissions).
> >
> > So if you don't want to follow-up on this series to polish the patch
> > descriptions etc,, let me now and I (or someone else around here) can
> > drag it over the finishing line.
>
> Thanks David - I do want to finish this, if there is a constructive
> path ahead. I know what you want, but I'm not so sure about the
> others.
>
> I can swap all verbose patch messages with the one you suggested.
> Would everybody agree that David's suggestion was enough text?

I'm fine with:

"constify shmem related test functions for improved const-correctness."

In the summary line, but, as I said on review, with a little more detail as
to what you're doing in that specific file underneath.

You don't necessarily have to list every function, but just to give a sense of
_why_ you chose those.

For instance:

	mm: constify shmem related test functions for improved const-correctness

	We select certain test functions which either invoke each other,
	functions that are already const-ified, or no further functions.

	It is therefore relatively trivial to const-ify them, which
	provides a basis for further const-ification further up the call
	stack.


You can re-use this kind of text for each adjusting sensibly as you go and
noting the dependency as you mentioned I think at 6/12?

Just something that clearly expresses what's going on in plain English.

Cheers, Lorenzo

On 01.09.25 13:05, Lorenzo Stoakes wrote:
> On Mon, Sep 01, 2025 at 12:54:40PM +0200, Max Kellermann wrote:
>> On Mon, Sep 1, 2025 at 12:43 PM David Hildenbrand <david@redhat.com> wrote:
>>> Max, I think this series here is valuable, and you can see that from the
>>> engagement from reviewers (this is a *good* thing, I sometimes wish I
>>> would get feedback that would help me improve my submissions).
>>>
>>> So if you don't want to follow-up on this series to polish the patch
>>> descriptions etc,, let me now and I (or someone else around here) can
>>> drag it over the finishing line.
>>
>> Thanks David - I do want to finish this, if there is a constructive
>> path ahead. I know what you want, but I'm not so sure about the
>> others.
>>
>> I can swap all verbose patch messages with the one you suggested.
>> Would everybody agree that David's suggestion was enough text?
> 
> I'm fine with:
> 
> "constify shmem related test functions for improved const-correctness."
> 
> In the summary line, but, as I said on review, with a little more detail as
> to what you're doing in that specific file underneath.
> 
> You don't necessarily have to list every function, but just to give a sense of
> _why_ you chose those.
> 
> For instance:
> 
> 	mm: constify shmem related test functions for improved const-correctness
> 
> 	We select certain test functions which either invoke each other,
> 	functions that are already const-ified, or no further functions.
> 
> 	It is therefore relatively trivial to const-ify them, which
> 	provides a basis for further const-ification further up the call
> 	stack.

Yes, that covers the what/why/why okay. For me something shorter would 
be acceptable as well in this case (as explained, due to "test 
functions" semantics), but as long as we're not in the AI-slop range of 
text, all good with me.

-- 
Cheers

David / dhildenb

On 01.09.25 12:54, Max Kellermann wrote:
> On Mon, Sep 1, 2025 at 12:43 PM David Hildenbrand <david@redhat.com> wrote:
>> Max, I think this series here is valuable, and you can see that from the
>> engagement from reviewers (this is a *good* thing, I sometimes wish I
>> would get feedback that would help me improve my submissions).
>>
>> So if you don't want to follow-up on this series to polish the patch
>> descriptions etc,, let me now and I (or someone else around here) can
>> drag it over the finishing line.
> 
> Thanks David - I do want to finish this, if there is a constructive
> path ahead. I know what you want, but I'm not so sure about the
> others.

I think we primarily want to briefly explain the what, the why, and why it is okay.

For getter/test functions the "why it is okay" it's trivial -- test function.
Personally, I would not spell out the individual functions in that case, as
long as they logically belong together (like "shmem test functions"
describe what you did in that patch).

For anything beyond that people likely expect a different reasoning.

For example the following change:

-static inline void folio_migrate_refs(struct folio *new, struct folio *old)
+static inline void folio_migrate_refs(struct folio *const new,
+				      const struct folio *const old)

Adds two "const" ways of doing things. As a reviewer, seeing something like that
buried in a patch raises questionmarks.

-- 
Cheers

David / dhildenb