From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from canpmsgout04.his.huawei.com (canpmsgout04.his.huawei.com [113.46.200.219]) (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 02E4439EF2F for ; Wed, 4 Mar 2026 10:08:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=113.46.200.219 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772618904; cv=none; b=j/ZTWg7UBtv5TorEdAbBUlUGHIXOFEaISN2DDl1MRmqJAxicmX8pwcfxatTrgLdiBkyDGZ8ErcYbV5TTCLHDx9ktK0lOweFr1buCQTj6CZF9QcLX+12KFlbEiGWQxZtY7cc21/PVT5yfPXpljA9sAjmhRKLeckCC0zlOGIe6jGI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1772618904; c=relaxed/simple; bh=I5nElCpr/sRp+aJDuUqV75LfiYKgpuE5x90e5gyhHYE=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=aWkztOkU31l8MnaShYOG5BEylf5sjJsNVVi2HeFC+Mbkybo92mOS5rBAbn9RREPWOHW747GZUjEx2fFhS/WN1zBBrh3CcMTwKzP0DaHMX4oBz1LL26S3UCQIvzXBS7itZQPjClpSwQPkXu3FivCEgRVv6LwGlswUqFyBhyZzUTI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com; spf=pass smtp.mailfrom=huawei.com; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b=3Sd8e7Il; arc=none smtp.client-ip=113.46.200.219 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=huawei.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=huawei.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=huawei.com header.i=@huawei.com header.b="3Sd8e7Il" dkim-signature: v=1; a=rsa-sha256; d=huawei.com; s=dkim; c=relaxed/relaxed; q=dns/txt; h=From; bh=+3GcVJzJOaMrQj6u+FGtRxjCJVOJSzeAFf3bB9pddjs=; b=3Sd8e7IlxgM+6czm7SzeGmkr1MLLDXO3tCM90f/PRMZbGdwZOlHMpSuUd0Q7wVWYXYDDWFnoe ifUJTiBz8rrZ+72EuC7XFQzC7tBFGqehMQ2spOylh/k/yN9fCSWrN12T24KcxcjdV8ejC7I90vW 4/cJZkYdSaqj2n/xxhpwW1g= Received: from mail.maildlp.com (unknown [172.19.162.197]) by canpmsgout04.his.huawei.com (SkyGuard) with ESMTPS id 4fQpCJ5647z1prkr; Wed, 4 Mar 2026 18:03:24 +0800 (CST) Received: from kwepemr500001.china.huawei.com (unknown [7.202.194.229]) by mail.maildlp.com (Postfix) with ESMTPS id 2A63C40363; Wed, 4 Mar 2026 18:08:18 +0800 (CST) Received: from [10.174.179.248] (10.174.179.248) by kwepemr500001.china.huawei.com (7.202.194.229) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Wed, 4 Mar 2026 18:08:16 +0800 Message-ID: <204de22f-335a-46f3-8f96-f1cbdcf7f2bf@huawei.com> Date: Wed, 4 Mar 2026 18:08:15 +0800 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 RFC v3 2/4] mm/pgtable: Make pfn_pte() filter out huge page attributes To: =?UTF-8?B?SsO8cmdlbiBHcm/Dnw==?= , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , CC: , References: <20260228070906.1418911-1-yintirui@huawei.com> <20260228070906.1418911-3-yintirui@huawei.com> <5eaf3846-01db-471e-9903-b0b239d7838d@suse.com> From: Yin Tirui In-Reply-To: <5eaf3846-01db-471e-9903-b0b239d7838d@suse.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-ClientProxiedBy: kwepems200002.china.huawei.com (7.221.188.68) To kwepemr500001.china.huawei.com (7.202.194.229) On 3/4/2026 3:52 PM, Jürgen Groß wrote: > On 28.02.26 08:09, Yin Tirui wrote: >> A fundamental principle of page table type safety is that `pte_t` >> represents >> the lowest level page table entry and should never carry huge page >> attributes. >> >> Currently, passing a pgprot with huge page bits (e.g., extracted via >> pmd_pgprot()) into pfn_pte() creates a malformed PTE that retains the >> huge >> attribute, leading to the necessity of the ugly `pte_clrhuge()` anti- >> pattern. >> >> Enforce type safety by making `pfn_pte()` inherently filter out huge page >> attributes: >> - On x86: Strip the `_PAGE_PSE` bit. >> - On ARM64: Mask out the block descriptor bits in `PTE_TYPE_MASK` and >>    enforce the `PTE_TYPE_PAGE` format. >> - On RISC-V: No changes required, as RISC-V leaf PMDs and PTEs share the >>    exact same hardware format and do not use a distinct huge bit. >> >> Signed-off-by: Yin Tirui >> --- >>   arch/arm64/include/asm/pgtable.h | 4 +++- >>   arch/x86/include/asm/pgtable.h   | 4 ++++ >>   2 files changed, 7 insertions(+), 1 deletion(-) >> >> diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/ >> asm/pgtable.h >> index b3e58735c49b..f2a7a40106d2 100644 >> --- a/arch/arm64/include/asm/pgtable.h >> +++ b/arch/arm64/include/asm/pgtable.h >> @@ -141,7 +141,9 @@ static inline pteval_t >> __phys_to_pte_val(phys_addr_t phys) >>   #define pte_pfn(pte)        (__pte_to_phys(pte) >> PAGE_SHIFT) >>   #define pfn_pte(pfn,prot)    \ >> -    __pte(__phys_to_pte_val((phys_addr_t)(pfn) << PAGE_SHIFT) | >> pgprot_val(prot)) >> +    __pte(__phys_to_pte_val((phys_addr_t)(pfn) << PAGE_SHIFT) | \ >> +        ((pgprot_val(prot) & ~(PTE_TYPE_MASK & ~PTE_VALID)) | \ >> +        (PTE_TYPE_PAGE & ~PTE_VALID))) >>   #define pte_none(pte)        (!pte_val(pte)) >>   #define pte_page(pte)        (pfn_to_page(pte_pfn(pte))) >> diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/ >> pgtable.h >> index 1662c5a8f445..a4dbd81d42bf 100644 >> --- a/arch/x86/include/asm/pgtable.h >> +++ b/arch/x86/include/asm/pgtable.h >> @@ -738,6 +738,10 @@ static inline pgprotval_t check_pgprot(pgprot_t >> pgprot) >>   static inline pte_t pfn_pte(unsigned long page_nr, pgprot_t pgprot) >>   { >>       phys_addr_t pfn = (phys_addr_t)page_nr << PAGE_SHIFT; >> + >> +    /* Filter out _PAGE_PSE to ensure PTEs never carry the huge page >> bit */ >> +    pgprot = __pgprot(pgprot_val(pgprot) & ~_PAGE_PSE); > > Is it really a good idea to silently drop the bit? > > Today it can either be used for a large page (which should be a pmd, > of course), or - much worse - you'd strip the _PAGE_PAT bit, which is > at the same position in PTEs. > > So basically you are removing the ability to use some cache modes. > > NACK! > > > Juergen Hi Jürgen, You are absolutely right. I missed the fact that `_PAGE_PSE` aliases with `_PAGE_PAT` on 4K PTEs. The intention here was to follow previous feedback to enforce type safety by filtering out huge page attributes directly inside `pfn_pte()`. However, doing it this way obviously breaks the cache modes on x86. I agree with the NACK. I will drop this approach and rethink how to handle the huge-to-normal pgprot conversion safely for v4. -- Thanks, Yin Tirui