Re: [PATCH v1 0/8] Fix set_huge_pte_at() panic on arm64
From: Ryan Roberts <ryan.roberts@arm.com>
Date: 2023-09-22 07:43:00
Also in:
linux-arm-kernel, linux-mm, linux-riscv, linux-s390, lkml, sparclinux, stable
On 21/09/2023 18:38, Catalin Marinas wrote:
On Thu, Sep 21, 2023 at 05:35:54PM +0100, Ryan Roberts wrote:quoted
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.
OK I'll do it like this for v2.