All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Red Hat)" <david@kernel.org>
To: "Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
	Ankur Arora <ankur.a.arora@oracle.com>,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org, x86@kernel.org
Cc: 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: Mon, 24 Nov 2025 15:02:51 +0100	[thread overview]
Message-ID: <ff7b2ca9-d4d7-41b3-acd8-2d90294e59cd@kernel.org> (raw)
In-Reply-To: <d3d68f78-bd76-4cf2-b20f-a0f7c838124a@kernel.org>

On 11/24/25 11:17, David Hildenbrand (Red Hat) wrote:
> On 11/23/25 12:53, Christophe Leroy (CS GROUP) wrote:
>>
>>
>> Le 21/11/2025 à 21:23, Ankur Arora a écrit :
>>> From: David Hildenbrand <david@redhat.com>
>>>
>>> Let's drop all variants that effectively map to clear_page() and
>>> provide it in a generic variant instead.
>>>
>>> We'll use the macro clear_user_page to indicate whether an architecture
>>> provides it's own variant.
>>>
>>> We have to be a bit careful if an architecture provides a custom
>>> clear_user_highpage(), because then it's very likely that some special
>>> flushing magic is happening behind the scenes.
>>>
>>> Maybe at some point these should be CONFIG_ options.
>>>
>>> Note that for parisc, clear_page() and clear_user_page() map to
>>> clear_page_asm(), so we can just get rid of the custom clear_user_page()
>>> implementation. There is a clear_user_page_asm() function on parisc,
>>> that seems to be unused. Not sure what's up with that.
>>>
>>> Signed-off-by: David Hildenbrand <david@redhat.com>
>>> Signed-off-by: Ankur Arora <ankur.a.arora@oracle.com>
>>
>> ...
>>
>>> diff --git a/include/linux/mm.h b/include/linux/mm.h
>>> index 7c79b3369b82..6fa6c188f99a 100644
>>> --- a/include/linux/mm.h
>>> +++ b/include/linux/mm.h
>>> @@ -3879,6 +3879,28 @@ static inline void clear_page_guard(struct zone *zone, struct page *page,
>>>     				unsigned int order) {}
>>>     #endif	/* CONFIG_DEBUG_PAGEALLOC */
>>>     
>>> +#ifndef clear_user_page
>>> +/**
>>> + * 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
>>> + */
>>> +static inline void clear_user_page(void *addr, unsigned long vaddr, struct page *page)
>>> +{
>>> +#ifdef clear_user_highpage
>>> +	/*
>>> +	 * If an architecture defines its own clear_user_highpage() variant,
>>> +	 * then we have to be a bit more careful here and cannot simply
>>> +	 * rely on clear_page().
>>> +	 */
>>> +	clear_user_highpage(page, vaddr);
>>> +#else
>>> +	clear_page(addr);
>>> +#endif
>>> +}
>>> +#endif
>>> +
>>>     #ifdef __HAVE_ARCH_GATE_AREA
>>>     extern struct vm_area_struct *get_gate_vma(struct mm_struct *mm);
>>>     extern int in_gate_area_no_mm(unsigned long addr);
>>
>>
>> Isn't it chicken and egg with clear_user_highpage() in linux/highmem.h ? :
> 
> No really, because we make use of clear_user_highpage() only when the
> arch defines it, so the highmem.h variant is ignored?
> 
> Not that I particularly enjoy this way of handling it, so something
> cleaner would be nice :)
> 
> (in particular, relying on highmem.h defines in mm.h is a bit suboptimal)

Correction: there is no highmem.h dependency, as clear_user_highpage() 
comes directly from the architecture helpers in page.h

-- 
Cheers

David


  reply	other threads:[~2025-11-24 14:03 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) [this message]
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
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=ff7b2ca9-d4d7-41b3-acd8-2d90294e59cd@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=ankur.a.arora@oracle.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=bp@alien8.de \
    --cc=chleroy@kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --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.