[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <38c0fbaf-cbb1-4f43-9d45-31ca642d1ed6@kernel.org>
Date: Wed, 7 Jan 2026 23:08:29 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Ankur Arora <ankur.a.arora@...cle.com>, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, x86@...nel.org
Cc: akpm@...ux-foundation.org, bp@...en8.de, dave.hansen@...ux.intel.com,
hpa@...or.com, mingo@...hat.com, mjguzik@...il.com, luto@...nel.org,
peterz@...radead.org, tglx@...utronix.de, willy@...radead.org,
raghavendra.kt@....com, chleroy@...nel.org, ioworker0@...il.com,
lizhe.67@...edance.com, boris.ostrovsky@...cle.com, konrad.wilk@...cle.com
Subject: Re: [PATCH v11 3/8] highmem: introduce clear_user_highpages()
On 1/7/26 08:20, Ankur Arora wrote:
> Define clear_user_highpages() which uses the range clearing primitive,
> clear_user_pages(). We can safely use this when CONFIG_HIGHMEM is
> disabled and if the architecture does not have clear_user_highpage.
>
> The first is needed to ensure that contiguous page ranges stay
> contiguous which precludes intermediate maps via HIGMEM.
> The second, because if the architecture has clear_user_highpage(),
> it likely needs flushing magic when clearing the page, magic that
> we aren't privy to.
>
> For both of those cases, just fallback to a loop around
> clear_user_highpage().
>
> Signed-off-by: Ankur Arora <ankur.a.arora@...cle.com>
> ---
> include/linux/highmem.h | 45 ++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 44 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/highmem.h b/include/linux/highmem.h
> index 019ab7d8c841..af03db851a1d 100644
> --- a/include/linux/highmem.h
> +++ b/include/linux/highmem.h
> @@ -251,7 +251,14 @@ static inline void clear_user_pages(void *addr, unsigned long vaddr,
> #endif
> }
>
> -/* when CONFIG_HIGHMEM is not set these will be plain clear/copy_page */
> +/**
> + * clear_user_highpage() - clear a page to be mapped to user space
Just a minor comment as I am skimming the patches: I recall kerneldoc
does not require the "()" here. But I also recall that it doesn't hurt :)
Acked-by: David Hildenbrand (Red Hat) <david@...nel.org>
--
Cheers
David
Powered by blists - more mailing lists