From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1BDC5C5B543 for ; Tue, 10 Jun 2025 16:18:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 7D38F6B0089; Tue, 10 Jun 2025 12:18:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 75D746B008A; Tue, 10 Jun 2025 12:18:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 625336B0092; Tue, 10 Jun 2025 12:18:17 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 3CABF6B0089 for ; Tue, 10 Jun 2025 12:18:17 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 9E753140828 for ; Tue, 10 Jun 2025 16:18:16 +0000 (UTC) X-FDA: 83539998192.27.150E6BB Received: from mailout1.w1.samsung.com (mailout1.w1.samsung.com [210.118.77.11]) by imf08.hostedemail.com (Postfix) with ESMTP id B917116001C for ; Tue, 10 Jun 2025 16:18:13 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=Qrb5syym; spf=pass (imf08.hostedemail.com: domain of m.szyprowski@samsung.com designates 210.118.77.11 as permitted sender) smtp.mailfrom=m.szyprowski@samsung.com; dmarc=pass (policy=none) header.from=samsung.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1749572294; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=pE6uccDncawBTaeE/O1XebhcejC0XaTINrmaJXRgnJw=; b=4wrHX6NFB9ITaIh/ovT8hKDRWZLt9K/l5Nl6cMU3KnmAagxURkUJM3yxidHVcBMqOncTjj cfqL8HZBrWH5t0R+VGNok3AXjIrI3p19nX/IxXa4blowLaooTRYSHhn2DwCAZjnBSI1pwq hylyYigELc9VqlB6j+WmyxTvgbtjOrE= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1749572294; a=rsa-sha256; cv=none; b=RHyF5bHK4HdvQB2/LrQ93v0HL11a/sPe1enWxdumDAhFGXzRsI1aQ4eg5by8dJXhKpz27C andR5hE8WrofecNBy7Vt7vHSN4ef8pS317zUCWcSUrJQIZC5SjFi/t/zoWD01vT+w2UsSE yFExoe2ioAgDaDonu7+rNuSyQ/txNU4= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=samsung.com header.s=mail20170921 header.b=Qrb5syym; spf=pass (imf08.hostedemail.com: domain of m.szyprowski@samsung.com designates 210.118.77.11 as permitted sender) smtp.mailfrom=m.szyprowski@samsung.com; dmarc=pass (policy=none) header.from=samsung.com Received: from eucas1p2.samsung.com (unknown [182.198.249.207]) by mailout1.w1.samsung.com (KnoxPortal) with ESMTP id 20250610161811euoutp01862c6c6daccc673f13c3d6d4872a255a~HurrRm8SP1190911909euoutp018 for ; Tue, 10 Jun 2025 16:18:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 mailout1.w1.samsung.com 20250610161811euoutp01862c6c6daccc673f13c3d6d4872a255a~HurrRm8SP1190911909euoutp018 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samsung.com; s=mail20170921; t=1749572291; bh=pE6uccDncawBTaeE/O1XebhcejC0XaTINrmaJXRgnJw=; h=Date:Subject:To:Cc:From:In-Reply-To:References:From; b=Qrb5syymTTlgVW1CdHrabdecFe+3HW/W0tOjr+seluTlv+QTE59KG65YpUlLRDqUE eLvfvG9qAWD3EJ75jQAFHSLCrsl5fhvWNnxIIY5dSIhgwUlumI2Gtulg1b711TS1yV SHnK3kgMwPL1wtmCuVmI2yCbxZYcV99JLZhIYlno= Received: from eusmtip2.samsung.com (unknown [203.254.199.222]) by eucas1p1.samsung.com (KnoxPortal) with ESMTPA id 20250610161811eucas1p18de4ba7b320b6d6ff7da44786b350b6e~Hurq601QC1524815248eucas1p1F; Tue, 10 Jun 2025 16:18:11 +0000 (GMT) Received: from [106.210.134.192] (unknown [106.210.134.192]) by eusmtip2.samsung.com (KnoxPortal) with ESMTPA id 20250610161809eusmtip2eda1a549605472f8ef4597e13d09bde6~HurpBKaGe2938129381eusmtip2F; Tue, 10 Jun 2025 16:18:09 +0000 (GMT) Message-ID: <957c0d9d-2c37-4d5f-a8b8-8bf90cd0aedb@samsung.com> Date: Tue, 10 Jun 2025 18:18:09 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: Remove PFN_MAP, PFN_SPECIAL, PFN_SG_CHAIN and PFN_SG_LAST To: Alistair Popple , linux-mm@kvack.org, akpm@linux-foundation.org, "linux-riscv@lists.infradead.org" Cc: David Hildenbrand , Christoph Hellwig , Jason Gunthorpe , gerald.schaefer@linux.ibm.com, dan.j.williams@intel.com, jgg@ziepe.ca, willy@infradead.org, linux-kernel@vger.kernel.org, nvdimm@lists.linux.dev, jhubbard@nvidia.com, zhang.lyra@gmail.com, debug@rivosinc.com, bjorn@kernel.org, balbirs@nvidia.com, lorenzo.stoakes@oracle.com, John@Groves.net Content-Language: en-US From: Marek Szyprowski In-Reply-To: <20250604032145.463934-1-apopple@nvidia.com> Content-Transfer-Encoding: 8bit X-CMS-MailID: 20250610161811eucas1p18de4ba7b320b6d6ff7da44786b350b6e X-Msg-Generator: CA Content-Type: text/plain; charset="utf-8" X-RootMTR: 20250610161811eucas1p18de4ba7b320b6d6ff7da44786b350b6e X-EPHeader: CA X-CMS-RootMailID: 20250610161811eucas1p18de4ba7b320b6d6ff7da44786b350b6e References: <20250604032145.463934-1-apopple@nvidia.com> X-Rspam-User: X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: B917116001C X-Stat-Signature: naa1gfbbf1wt7ftmmjm7ijbhawijfsb9 X-HE-Tag: 1749572293-474914 X-HE-Meta: U2FsdGVkX1+exbGeT7xJmCJD8iSyoFv8GVJ1AA8KLoIBHs5bHgDsfEegwstoEx/q12yGMGgKFtQwFwZUQbwNimmWea99oAPvW0HdD1yqLeytwOumpOIGE+P70yLeiK9oHtEaQTxxVsSFt/ZaSm9wuFdVckM1UVMCE215c1sckN3raIloAz2gEzQXDNz+Jxuy9gpc0y5fIPejRsEZ7oFcRsGBdR7OBHD569aKkcHgjbqxWe5cw+oe/FTj1lOEDuX68XT++nIItB69RFs43cVdJD6qGCiXjbHT5ypk5dHWA+i5cK48dBL0qVxrf68MVAIYJ8FziZMwNNC9GVLiCzF43hx+K+/nhkmG3KhJzWRGS86LwiElBBOKcAPoHx4cnax45CuoUcTwId8nB6rG0kfuhoV4s2W6PLb49OfwvoNX3Gf6fdQcQ8YP69GaTPmpQmYkt+8RwlgREX39Ry8IPc9aivZJ17XjxVPGFfhmi1IIpWZVvBVXzcCNb+Ib6NkAfkFbW7Rxs08yKhblyfSpV5BfBb+qLKrmL7hhZLchwH+EgbjKQ8d7XEcEyalMgCsq37p4ynCbTKvDkKmRyXHzun0tVT/uXfiLRkBxAQS3MvUrobJCSYAoC2nrslX+pwZoL6YSZj4nuuuKFtV5YSsWlPOiCOJ1EHlkK0uuLRF12N2asLjxh4ukXj/pRBg7KfXNKGJNH99ySQ0jytBosgzWvRVfwqFmctahSWHdEGVRtV2B+4CvlCvKYZrCe9IIeZ3KyS5xMM3h/Q7PBS9QGVqAj1ZvPNmTJLSHSSa/cYPOg1Ms0IJNT0w5XiJPY7LRfp+vB6QRyO1Knk5K3EHWbIeh3p0fBlFOQoZZfXlyncjraNrltGV51wyZjpUW95qVflYd05jfPu6jZDeUWe+amDnadYlq+p5AxaFh5g+MpOqO8FxgEmsPJ7viS5OgSBYbMUXkL3iZMyB9gOCOzuLjyrVhh9u 4iiUayZ6 gtzk3zSm9DfAw8aAsueAxmwXPoh33zbBsrxs8qxhlX6U2Usbo+vAB1yMDObQq9WuBlOTDg184/2sY6f8TeBs+P06HSv4JCECo+GwzuHxhj/BXegQ7gmzQSfabvTuZmmOq+dfEVajcDoh8L+rSrjSiswlnlAhVQMDQNC9lawn9DTYBDGldo/INdI+ybOn8SxR2jwVGd21lR3VI3CK8toVSnlpjU+WyFob+T8aJdl85TKYHob/M+9swofAcWF0przZOhgpNtDsXb7+83iSB2d0kxeS0jLFEUicawakU X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: Dear All, On 04.06.2025 05:21, Alistair Popple wrote: > The PFN_MAP flag is no longer used for anything, so remove it. > The PFN_SG_CHAIN and PFN_SG_LAST flags never appear to have been > used so also remove them. The last user of PFN_SPECIAL was removed > by 653d7825c149 ("dcssblk: mark DAX broken, remove FS_DAX_LIMITED > support"). > > Signed-off-by: Alistair Popple > Acked-by: David Hildenbrand > Reviewed-by: Christoph Hellwig > Reviewed-by: Jason Gunthorpe > Cc: gerald.schaefer@linux.ibm.com > Cc: dan.j.williams@intel.com > Cc: jgg@ziepe.ca > Cc: willy@infradead.org > Cc: david@redhat.com > Cc: linux-kernel@vger.kernel.org > Cc: nvdimm@lists.linux.dev > Cc: jhubbard@nvidia.com > Cc: hch@lst.de > Cc: zhang.lyra@gmail.com > Cc: debug@rivosinc.com > Cc: bjorn@kernel.org > Cc: balbirs@nvidia.com > Cc: lorenzo.stoakes@oracle.com > Cc: John@Groves.net > > --- > > Splitting this off from the rest of my series[1] as a separate clean-up > for consideration for the v6.16 merge window as suggested by Christoph. > > [1] - https://lore.kernel.org/linux-mm/cover.541c2702181b7461b84f1a6967a3f0e823023fcc.1748500293.git-series.apopple@nvidia.com/ > --- > include/linux/pfn_t.h | 31 +++---------------------------- > mm/memory.c | 2 -- > tools/testing/nvdimm/test/iomap.c | 4 ---- > 3 files changed, 3 insertions(+), 34 deletions(-) This patch landed in today's linux-next as commit 28be5676b4a3 ("mm: remove PFN_MAP, PFN_SPECIAL, PFN_SG_CHAIN and PFN_SG_LAST"). In my tests I've noticed that it breaks operation of all RISC-V 64bit boards on my test farm (VisionFive2, BananaPiF3 as well as QEMU's Virt machine). I've isolated the changes responsible for this issue, see the inline comments in the patch below. Here is an example of the issues observed in the logs from those machines: BUG: Bad page map in process modprobe  pte:20682653 pmd:20f23c01 page: refcount:1 mapcount:-1 mapping:0000000000000000 index:0x0 pfn:0x81a09 flags: 0x2004(referenced|reserved|zone=0) raw: 0000000000002004 ff1c000000068248 ff1c000000068248 0000000000000000 raw: 0000000000000000 0000000000000000 00000001fffffffe 0000000000000000 page dumped because: bad pte addr:00007fff84619000 vm_flags:04044411 anon_vma:0000000000000000 mapping:0000000000000000 index:0 file:(null) fault:special_mapping_fault mmap:0x0 mmap_prepare: 0x0 read_folio:0x0 CPU: 1 UID: 0 PID: 58 Comm: modprobe Not tainted 6.16.0-rc1-next-20250610+ #15719 NONE Hardware name: riscv-virtio,qemu (DT) Call Trace: [] dump_backtrace+0x1c/0x24 [] show_stack+0x28/0x34 [] dump_stack_lvl+0x5e/0x86 [] dump_stack+0x14/0x1c [] print_bad_pte+0x1b4/0x1ee [] unmap_page_range+0x4da/0xf74 [] unmap_single_vma.constprop.0+0x5e/0x90 [] unmap_vmas+0xc6/0x1c4 [] exit_mmap+0xb6/0x418 [] mmput+0x56/0xf2 [] do_exit+0x182/0x80e [] do_group_exit+0x24/0x70 [] pid_child_should_wake+0x0/0x54 [] do_trap_ecall_u+0x29c/0x4cc [] handle_exception+0x146/0x152 Disabling lock debugging due to kernel taint > diff --git a/include/linux/pfn_t.h b/include/linux/pfn_t.h > index 2d9148221e9a..46afa12eb33b 100644 > --- a/include/linux/pfn_t.h > +++ b/include/linux/pfn_t.h > @@ -5,26 +5,13 @@ > > /* > * PFN_FLAGS_MASK - mask of all the possible valid pfn_t flags > - * PFN_SG_CHAIN - pfn is a pointer to the next scatterlist entry > - * PFN_SG_LAST - pfn references a page and is the last scatterlist entry > * PFN_DEV - pfn is not covered by system memmap by default > - * PFN_MAP - pfn has a dynamic page mapping established by a device driver > - * PFN_SPECIAL - for CONFIG_FS_DAX_LIMITED builds to allow XIP, but not > - * get_user_pages > */ > #define PFN_FLAGS_MASK (((u64) (~PAGE_MASK)) << (BITS_PER_LONG_LONG - PAGE_SHIFT)) > -#define PFN_SG_CHAIN (1ULL << (BITS_PER_LONG_LONG - 1)) > -#define PFN_SG_LAST (1ULL << (BITS_PER_LONG_LONG - 2)) > #define PFN_DEV (1ULL << (BITS_PER_LONG_LONG - 3)) > -#define PFN_MAP (1ULL << (BITS_PER_LONG_LONG - 4)) > -#define PFN_SPECIAL (1ULL << (BITS_PER_LONG_LONG - 5)) > > #define PFN_FLAGS_TRACE \ > - { PFN_SPECIAL, "SPECIAL" }, \ > - { PFN_SG_CHAIN, "SG_CHAIN" }, \ > - { PFN_SG_LAST, "SG_LAST" }, \ > - { PFN_DEV, "DEV" }, \ > - { PFN_MAP, "MAP" } > + { PFN_DEV, "DEV" } > > static inline pfn_t __pfn_to_pfn_t(unsigned long pfn, u64 flags) > { > @@ -46,7 +33,7 @@ static inline pfn_t phys_to_pfn_t(phys_addr_t addr, u64 flags) > > static inline bool pfn_t_has_page(pfn_t pfn) > { > - return (pfn.val & PFN_MAP) == PFN_MAP || (pfn.val & PFN_DEV) == 0; > + return (pfn.val & PFN_DEV) == 0; > } > > static inline unsigned long pfn_t_to_pfn(pfn_t pfn) > @@ -100,7 +87,7 @@ static inline pud_t pfn_t_pud(pfn_t pfn, pgprot_t pgprot) > #ifdef CONFIG_ARCH_HAS_PTE_DEVMAP > static inline bool pfn_t_devmap(pfn_t pfn) > { > - const u64 flags = PFN_DEV|PFN_MAP; > + const u64 flags = PFN_DEV; > > return (pfn.val & flags) == flags; > } The above change causes the stability issues on RISC-V based boards. To get them working again with today's linux-next I had to apply the following change: diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 6ff7dd305639..f502860f2a76 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -46,7 +46,6 @@ config RISCV         select ARCH_HAS_PREEMPT_LAZY         select ARCH_HAS_PREPARE_SYNC_CORE_CMD         select ARCH_HAS_PTDUMP if MMU -       select ARCH_HAS_PTE_DEVMAP if 64BIT && MMU         select ARCH_HAS_PTE_SPECIAL         select ARCH_HAS_SET_DIRECT_MAP if MMU         select ARCH_HAS_SET_MEMORY if MMU I'm not sure if this is really the desired solution and frankly speaking I don't understand the code behind the 'devmap' related bits. I can help testing other patches that will fix this issue properly. > @@ -116,16 +103,4 @@ pmd_t pmd_mkdevmap(pmd_t pmd); > pud_t pud_mkdevmap(pud_t pud); > #endif > #endif /* CONFIG_ARCH_HAS_PTE_DEVMAP */ > - > -#ifdef CONFIG_ARCH_HAS_PTE_SPECIAL > -static inline bool pfn_t_special(pfn_t pfn) > -{ > - return (pfn.val & PFN_SPECIAL) == PFN_SPECIAL; > -} > -#else > -static inline bool pfn_t_special(pfn_t pfn) > -{ > - return false; > -} > -#endif /* CONFIG_ARCH_HAS_PTE_SPECIAL */ > #endif /* _LINUX_PFN_T_H_ */ > diff --git a/mm/memory.c b/mm/memory.c > index 49199410805c..cc85f814bc1c 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -2569,8 +2569,6 @@ static bool vm_mixed_ok(struct vm_area_struct *vma, pfn_t pfn, bool mkwrite) > return true; > if (pfn_t_devmap(pfn)) > return true; > - if (pfn_t_special(pfn)) > - return true; > if (is_zero_pfn(pfn_t_to_pfn(pfn))) > return true; > return false; > diff --git a/tools/testing/nvdimm/test/iomap.c b/tools/testing/nvdimm/test/iomap.c > index e4313726fae3..ddceb04b4a9a 100644 > --- a/tools/testing/nvdimm/test/iomap.c > +++ b/tools/testing/nvdimm/test/iomap.c > @@ -137,10 +137,6 @@ EXPORT_SYMBOL_GPL(__wrap_devm_memremap_pages); > > pfn_t __wrap_phys_to_pfn_t(phys_addr_t addr, unsigned long flags) > { > - struct nfit_test_resource *nfit_res = get_nfit_res(addr); > - > - if (nfit_res) > - flags &= ~PFN_MAP; > return phys_to_pfn_t(addr, flags); > } > EXPORT_SYMBOL(__wrap_phys_to_pfn_t); Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland