[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <957c0d9d-2c37-4d5f-a8b8-8bf90cd0aedb@samsung.com>
Date: Tue, 10 Jun 2025 18:18:09 +0200
From: Marek Szyprowski <m.szyprowski@...sung.com>
To: Alistair Popple <apopple@...dia.com>, linux-mm@...ck.org,
akpm@...ux-foundation.org, "linux-riscv@...ts.infradead.org"
<linux-riscv@...ts.infradead.org>
Cc: David Hildenbrand <david@...hat.com>, Christoph Hellwig <hch@....de>,
Jason Gunthorpe <jgg@...dia.com>, gerald.schaefer@...ux.ibm.com,
dan.j.williams@...el.com, jgg@...pe.ca, willy@...radead.org,
linux-kernel@...r.kernel.org, nvdimm@...ts.linux.dev, jhubbard@...dia.com,
zhang.lyra@...il.com, debug@...osinc.com, bjorn@...nel.org,
balbirs@...dia.com, lorenzo.stoakes@...cle.com, John@...ves.net
Subject: Re: [PATCH] mm: Remove PFN_MAP, PFN_SPECIAL, PFN_SG_CHAIN and
PFN_SG_LAST
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 <apopple@...dia.com>
> Acked-by: David Hildenbrand <david@...hat.com>
> Reviewed-by: Christoph Hellwig <hch@....de>
> Reviewed-by: Jason Gunthorpe <jgg@...dia.com>
> Cc: gerald.schaefer@...ux.ibm.com
> Cc: dan.j.williams@...el.com
> Cc: jgg@...pe.ca
> Cc: willy@...radead.org
> Cc: david@...hat.com
> Cc: linux-kernel@...r.kernel.org
> Cc: nvdimm@...ts.linux.dev
> Cc: jhubbard@...dia.com
> Cc: hch@....de
> Cc: zhang.lyra@...il.com
> Cc: debug@...osinc.com
> Cc: bjorn@...nel.org
> Cc: balbirs@...dia.com
> Cc: lorenzo.stoakes@...cle.com
> Cc: John@...ves.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:
[<ffffffff80016152>] dump_backtrace+0x1c/0x24
[<ffffffff8000147a>] show_stack+0x28/0x34
[<ffffffff8000f61e>] dump_stack_lvl+0x5e/0x86
[<ffffffff8000f65a>] dump_stack+0x14/0x1c
[<ffffffff80234b7e>] print_bad_pte+0x1b4/0x1ee
[<ffffffff8023854a>] unmap_page_range+0x4da/0xf74
[<ffffffff80239042>] unmap_single_vma.constprop.0+0x5e/0x90
[<ffffffff8023913a>] unmap_vmas+0xc6/0x1c4
[<ffffffff80244a70>] exit_mmap+0xb6/0x418
[<ffffffff80021dc4>] mmput+0x56/0xf2
[<ffffffff8002b84e>] do_exit+0x182/0x80e
[<ffffffff8002c02a>] do_group_exit+0x24/0x70
[<ffffffff8002c092>] pid_child_should_wake+0x0/0x54
[<ffffffff80b66112>] do_trap_ecall_u+0x29c/0x4cc
[<ffffffff80b747e6>] 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
Powered by blists - more mailing lists