Re: [PATCH v1 0/8] Fix set_huge_pte_at() panic on arm64
From: Catalin Marinas <catalin.marinas@arm.com>
Date: 2023-09-21 22:12:55
Also in:
linux-arm-kernel, linux-mm, linux-riscv, linux-s390, lkml, sparclinux, stable
On Thu, Sep 21, 2023 at 05:35:54PM +0100, Ryan Roberts wrote:
On 21/09/2023 17:30, Andrew Morton wrote:quoted
On Thu, 21 Sep 2023 17:19:59 +0100 Ryan Roberts [off-list ref] wrote:quoted
Ryan Roberts (8): parisc: hugetlb: Convert set_huge_pte_at() to take vma powerpc: hugetlb: Convert set_huge_pte_at() to take vma riscv: hugetlb: Convert set_huge_pte_at() to take vma s390: hugetlb: Convert set_huge_pte_at() to take vma sparc: hugetlb: Convert set_huge_pte_at() to take vma mm: hugetlb: Convert set_huge_pte_at() to take vma arm64: hugetlb: Convert set_huge_pte_at() to take vma arm64: hugetlb: Fix set_huge_pte_at() to work with all swap entries arch/arm64/include/asm/hugetlb.h | 2 +- arch/arm64/mm/hugetlbpage.c | 22 ++++---------- arch/parisc/include/asm/hugetlb.h | 2 +- arch/parisc/mm/hugetlbpage.c | 4 +-- .../include/asm/nohash/32/hugetlb-8xx.h | 3 +- arch/powerpc/mm/book3s64/hugetlbpage.c | 2 +- arch/powerpc/mm/book3s64/radix_hugetlbpage.c | 2 +- arch/powerpc/mm/nohash/8xx.c | 2 +- arch/powerpc/mm/pgtable.c | 7 ++++- arch/riscv/include/asm/hugetlb.h | 2 +- arch/riscv/mm/hugetlbpage.c | 3 +- arch/s390/include/asm/hugetlb.h | 8 +++-- arch/s390/mm/hugetlbpage.c | 8 ++++- arch/sparc/include/asm/hugetlb.h | 8 +++-- arch/sparc/mm/hugetlbpage.c | 8 ++++- include/asm-generic/hugetlb.h | 6 ++-- include/linux/hugetlb.h | 6 ++-- mm/damon/vaddr.c | 2 +- mm/hugetlb.c | 30 +++++++++---------- mm/migrate.c | 2 +- mm/rmap.c | 10 +++---- mm/vmalloc.c | 5 +++- 22 files changed, 80 insertions(+), 64 deletions(-)Looks scary but it's actually a fairly modest patchset. It could easily be all rolled into a single patch for ease of backporting. Maybe Greg has an opinion?Yes, I thought about doing that; or perhaps 2 patches - one for the interface change across all arches and core code, and one for the actual bug fix?
I think this would make more sense, especially if we want to backport it. The first patch would have no functional change, only an interface change, followed by the arm64 fix. -- Catalin