From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8F1FB2D3A93 for ; Tue, 18 Nov 2025 07:32:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763451173; cv=none; b=UR5KG6Er2AsshwRgdWvWTd03e1lLwosVFsObsHqXb58Vov6Mpm3MlV498objxX9xBNQM2gM4u+LVV4pJnh2IAI09+EDrsp+A6E5VJWTmbEBbVfEXBWptEBisaudSsXppqVSuY3y9lQ9A7xlVu6zgg5Lf3QNzIQA2ragm2eP8o4o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763451173; c=relaxed/simple; bh=ApGJpvP5hKECH4jNdONY7ygRf50YGNmepwxYmKGJWWE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=X305urP/7xgeT55xhelPlxImtsNKlLO8vUXzeSi+HVczPaS/zn4PGIURjcSHcrhctHrsaasRjLTj4bp845e4vpJmSRJ+J93+9Z4unhyCLJZILkGOlK37CBhRKusHKIvPeAW2UzjbsXpIYcocxb+ioQRKGJmmGzhq1Zbb9DaKvpk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=Drs95Ujz; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="Drs95Ujz" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 90F94C4CEF5; Tue, 18 Nov 2025 07:32:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763451173; bh=ApGJpvP5hKECH4jNdONY7ygRf50YGNmepwxYmKGJWWE=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Drs95UjzV2nXp7/IzZfJ7oZb7Ii6iiEezfgE/hs+hBod40DDo5IVA8bnXKf8Ffl86 Z2Fy76KFc/LOZJtzBClVZ64sT6raCThm4ZXBfh/hT8gvV/oLZYyQ7PtkfzbLGM1bKx pQiKA++tpGr0REG34qybC3mXOr6GKmTH8iFdRPngJaTOBLQhSJKrAmDkCjbVDKcWDL 1Q8aaN9il7z5cUOH7iCCeQ+jsOYMaXR6J+2X4XmjZMrYRkzAoMqjaLmoYMtQ7GfSXg Pp2eFVC+iswWsGQf4vjJM2uqhWwswVpoICMKPS+1bWnaEYfK2vH3iBb4qKH0dFqQX0 8brthYY2aRZ0w== Message-ID: Date: Tue, 18 Nov 2025 08:32:46 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v8 1/7] treewide: provide a generic clear_user_page() variant To: Ankur Arora , 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, acme@kernel.org, namhyung@kernel.org, tglx@linutronix.de, willy@infradead.org, raghavendra.kt@amd.com, boris.ostrovsky@oracle.com, konrad.wilk@oracle.com References: <20251027202109.678022-1-ankur.a.arora@oracle.com> <20251027202109.678022-2-ankur.a.arora@oracle.com> From: "David Hildenbrand (Red Hat)" Content-Language: en-US In-Reply-To: <20251027202109.678022-2-ankur.a.arora@oracle.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 27.10.25 21:21, Ankur Arora wrote: > From: David Hildenbrand > > Let's drop all variants that effectively map to clear_page() and > provide it in a generic variant instead. > > We'll use __HAVE_ARCH_CLEAR_USER_PAGE, similar to > __HAVE_ARCH_COPY_USER_HIGHPAGE, 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 > --- > arch/alpha/include/asm/page.h | 1 - > arch/arc/include/asm/page.h | 2 ++ > arch/arm/include/asm/page-nommu.h | 1 - > arch/arm64/include/asm/page.h | 1 - > arch/csky/abiv1/inc/abi/page.h | 1 + > arch/csky/abiv2/inc/abi/page.h | 7 ------- > arch/hexagon/include/asm/page.h | 1 - > arch/loongarch/include/asm/page.h | 1 - > arch/m68k/include/asm/page_mm.h | 1 + > arch/m68k/include/asm/page_no.h | 1 - > arch/microblaze/include/asm/page.h | 1 - > arch/mips/include/asm/page.h | 1 + > arch/nios2/include/asm/page.h | 1 + > arch/openrisc/include/asm/page.h | 1 - > arch/parisc/include/asm/page.h | 1 - > arch/powerpc/include/asm/page.h | 1 + > arch/riscv/include/asm/page.h | 1 - > arch/s390/include/asm/page.h | 1 - > arch/sparc/include/asm/page_32.h | 2 ++ > arch/sparc/include/asm/page_64.h | 1 + > arch/um/include/asm/page.h | 1 - > arch/x86/include/asm/page.h | 6 ------ > arch/xtensa/include/asm/page.h | 1 - > include/linux/mm.h | 22 ++++++++++++++++++++++ > 24 files changed, 32 insertions(+), 26 deletions(-) > > diff --git a/arch/alpha/include/asm/page.h b/arch/alpha/include/asm/page.h > index 5ec4c77e432e..d71ef845deca 100644 > --- a/arch/alpha/include/asm/page.h > +++ b/arch/alpha/include/asm/page.h > @@ -11,7 +11,6 @@ > #define STRICT_MM_TYPECHECKS > > extern void clear_page(void *page); > -#define clear_user_page(page, vaddr, pg) clear_page(page) > > #define vma_alloc_zeroed_movable_folio(vma, vaddr) \ > vma_alloc_folio(GFP_HIGHUSER_MOVABLE | __GFP_ZERO, 0, vma, vaddr) > diff --git a/arch/arc/include/asm/page.h b/arch/arc/include/asm/page.h > index 9720fe6b2c24..cb4d69b473e6 100644 > --- a/arch/arc/include/asm/page.h > +++ b/arch/arc/include/asm/page.h > @@ -32,6 +32,8 @@ struct page; > > void copy_user_highpage(struct page *to, struct page *from, > unsigned long u_vaddr, struct vm_area_struct *vma); > + > +#define __HAVE_ARCH_CLEAR_USER_PAGE After talking to Linus, the preferred way here is using #define clear_user_page clear_user_page Can you adjust the patch (+description) to avoid __HAVE_ARCH_CLEAR_USER_PAGE? If you want me to do it, just let me know. -- Cheers David