All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ankur Arora <ankur.a.arora@oracle.com>
To: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>
Cc: Ankur Arora <ankur.a.arora@oracle.com>,
	"David Hildenbrand (Red Hat)" <david@kernel.org>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org,
	akpm@linux-foundation.org, bp@alien8.de,
	dave.hansen@linux.intel.com, hpa@zytor.com, mingo@redhat.com,
	mjguzik@gmail.com, luto@kernel.org, peterz@infradead.org,
	tglx@linutronix.de, willy@infradead.org, raghavendra.kt@amd.com,
	boris.ostrovsky@oracle.com, konrad.wilk@oracle.com
Subject: Re: [PATCH v9 1/7] treewide: provide a generic clear_user_page() variant
Date: Fri, 28 Nov 2025 14:19:45 -0800	[thread overview]
Message-ID: <87y0np4x6m.fsf@oracle.com> (raw)
In-Reply-To: <6d2605e8-409d-4b4a-9729-599dd2526b74@kernel.org>


Christophe Leroy (CS GROUP) <chleroy@kernel.org> writes:

> Hi Ankur,
>
> Le 28/11/2025 à 00:57, Ankur Arora a écrit :
>> Ankur Arora <ankur.a.arora@oracle.com> writes:
>>
>> How about something like this for clear_user_page() (though maybe I
>> should be always defining clear_user_page() and not conditioning it on
>> the existence of the generic clear_user_highpage()):
>> diff --git a/include/linux/highmem.h b/include/linux/highmem.h
>> index abc20f9810fd..ca9d28aa29b2 100644
>> --- a/include/linux/highmem.h
>> +++ b/include/linux/highmem.h
>> @@ -197,6 +197,22 @@ static inline void invalidate_kernel_vmap_range(void *vaddr, int size)
>>   }
>>   #endif
>> +#if !defined(clear_user_page) && !defined(clear_user_highpage)
>> +/**
>> + * clear_user_page() - clear a page to be mapped to user space
>> + * @addr: the address of the page
>> + * @vaddr: the address of the user mapping
>> + * @page: the page
>> + *
>> + * The sole user of clear_user_page() is clear_user_highpage().
>> + * Define it if the arch does not and only if needed.
>> + */
>> +static inline void clear_user_page(void *addr, unsigned long vaddr, struct page *page)
>> +{
>> +       clear_page(addr);
>> +}
>> +#endif
>
> WOuld be more obvious if you enclose that inside the same #ifdef as
> clear_user_highpage(), something like:

Yeah I was debating whether to do that or not.

> #ifndef clear_user_highpage
>
> #ifndef clear_user_page
> static inline void clear_user_page(void *addr, unsigned long vaddr, struct page
> *page)
> {
> 	clear_page(addr);
> }
> #endif
>
> static inline void clear_user_highpage(struct page *page, unsigned long vaddr)
> {
> 	void *addr = kmap_local_page(page);
> 	clear_user_page(addr, vaddr, page);
> 	kunmap_local(addr);
> }
> #endif

On second thoughts after the discussion below it's less confusing if I
didn't tie these two together:

 #ifndef clear_user_page
 static inline void clear_user_page(void *addr, unsigned long vaddr, struct page *page)
 {
 	clear_page(addr);
 }
 #endif

 #ifndef clear_user_highpage
 static inline void clear_user_highpage(struct page *page, unsigned long vaddr)
 {
 	void *addr = kmap_local_page(page);
 	clear_user_page(addr, vaddr, page);
 	kunmap_local(addr);
 }
 #endif

>> +
>>   /* when CONFIG_HIGHMEM is not set these will be plain clear/copy_page */
>>   #ifndef clear_user_highpage
>>   static inline void clear_user_highpage(struct page *page, unsigned long vaddr)
>> And for clear_user_pages():
>> diff --git a/include/linux/highmem.h b/include/linux/highmem.h
>> index ca9d28aa29b2..b9b3cc76a91a 100644
>> --- a/include/linux/highmem.h
>> +++ b/include/linux/highmem.h
>> @@ -223,6 +223,35 @@ static inline void clear_user_highpage(struct page *page, unsigned long vaddr)
>>   }
>>   #endif
>> +/**
>> + * clear_user_pages() - clear a page range to be mapped to user space
>> + * @addr: start address
>> + * @vaddr: start address of the user mapping
>> + * @page: start page
>> + * @npages: number of pages
>> + *
>> + * Assumes that the region (@addr, +@npages) has been validated
>> + * already so this does no exception handling.
>> + */
>> +static inline void clear_user_pages(void *addr, unsigned long vaddr,
>> +               struct page *page, unsigned int npages)
>> +{
>> +#ifdef clear_user_page
>> +       do {
>> +               clear_user_page(addr, vaddr, page);
>> +               addr += PAGE_SIZE;
>> +               vaddr += PAGE_SIZE;
>> +               page++;
>> +       } while (--npages);
>> +#else
>> +       /*
>> +        * Prefer clear_pages() to allow for architectural optimizations
>> +        * when operations on contiguous page ranges.
>> +        */
>> +       clear_pages(addr, npages);
>> +#endif
>> +}
>
> Not sure to understand the logic. You say this is not expected to be overriden
> by architectures in the near future, then why do we need that ? Can't we do
> everything inside clear_user_highpages() for clarity ?

clear_user_page[s]() is semantically different enough from clear_user_highpages()
that I don't think it makes sense to fuse the two.

For one thing, we would have to disentangle them again if/once CONFIG_HIGHMEM
goes away.

> At the time being clear_user_page() is used exclusively by clear_user_highpage()
> so I expect clear_user_page() to only exist when CONFIG_HIGHMEM is enabled. And

The generic clear_user_page() only exists if the generic clear_user_highpage()
is defined. The arch might provide a clear_user_page() of its own (ex.
arm/sparc etc).

> in that case clear_user_highpages() doesn't call clear_user_pages() so at the
> end only the else part remains, which is a simple call to clear_pages(). Why not
> just call clear_pages() directly from clear_user_highpages() and drop
> clear_user_pages() ?

For !HIGHMEM, the clear_user_pages() might be just clear_pages() or a
loop around an architecture specific clear_user_page().

--
ankur


  reply	other threads:[~2025-11-28 22:20 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-21 20:23 [PATCH v9 0/7] mm: folio_zero_user: clear contiguous pages Ankur Arora
2025-11-21 20:23 ` [PATCH v9 1/7] treewide: provide a generic clear_user_page() variant Ankur Arora
2025-11-23 11:53   ` Christophe Leroy (CS GROUP)
2025-11-24 10:17     ` David Hildenbrand (Red Hat)
2025-11-24 14:02       ` David Hildenbrand (Red Hat)
2025-11-25  7:52       ` Ankur Arora
2025-11-27 23:57         ` Ankur Arora
2025-11-28  7:39           ` Christophe Leroy (CS GROUP)
2025-11-28 22:19             ` Ankur Arora [this message]
2025-11-21 20:23 ` [PATCH v9 2/7] mm: introduce clear_pages() and clear_user_pages() Ankur Arora
2025-11-21 22:48   ` kernel test robot
2025-11-23 13:17   ` Christophe Leroy (CS GROUP)
2025-11-24 10:26     ` David Hildenbrand (Red Hat)
2025-11-28 10:13       ` Lance Yang
2025-11-28 21:59         ` Ankur Arora
2025-11-21 20:23 ` [PATCH v9 3/7] mm/highmem: introduce clear_user_highpages() Ankur Arora
2025-11-21 20:23 ` [PATCH v9 4/7] x86/mm: Simplify clear_page_* Ankur Arora
2025-11-25 13:47   ` Borislav Petkov
2025-11-25 19:01     ` Ankur Arora
2025-11-26 10:01   ` Mateusz Guzik
2025-11-27  5:28     ` Ankur Arora
2025-11-21 20:23 ` [PATCH v9 5/7] x86/clear_page: Introduce clear_pages() Ankur Arora
2025-11-21 20:23 ` [PATCH v9 6/7] mm, folio_zero_user: support clearing page ranges Ankur Arora
2025-11-21 20:23 ` [PATCH v9 7/7] mm: folio_zero_user: cache neighbouring pages Ankur Arora

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y0np4x6m.fsf@oracle.com \
    --to=ankur.a.arora@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@alien8.de \
    --cc=chleroy@kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@kernel.org \
    --cc=hpa@zytor.com \
    --cc=konrad.wilk@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=mjguzik@gmail.com \
    --cc=peterz@infradead.org \
    --cc=raghavendra.kt@amd.com \
    --cc=tglx@linutronix.de \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.