The quilt patch titled
Subject: mm/dax: dump start address in fault handler
has been removed from the -mm tree. Its filename was
mm-dax-dump-start-address-in-fault-handler.patch
This patch was dropped because an updated version will be issued
------------------------------------------------------
From: Peter Xu <peterx@xxxxxxxxxx>
Subject: mm/dax: dump start address in fault handler
Date: Wed, 7 Aug 2024 15:48:05 -0400
Patch series "mm/mprotect: Fix dax puds", v4.
Dax supports pud pages for a while, but mprotect on puds was missing since
the start.
The problem is mprotect() will skip the dax 1G PUD while it shouldn't;
meanwhile it'll dump some bad PUD in dmesg. Both of them look like (corner
case) bugs to me.. where:
- skipping the 1G pud means mprotect() will succeed even if the pud won't
be updated with the correct permission specified. Logically that can
cause e.g. in mprotect(RO) then write the page can cause data corrupt,
as the pud page will still be writable.
- the bad pud will generate a pr_err() into dmesg, with no limit so far I
can see. So I think it means an userspace can DoS the kernel log if it
wants.. simply by creating the PUD and keep mprotect-ing it
This series tries to fix that by providing pud handling in mprotect().
The goal is to add more types of pud mappings like hugetlb or pfnmaps.
This series paves way for it by fixing known pud entries.
Considering nobody reported this until when I looked at those other types
of pud mappings, I am thinking maybe it doesn't need to be a fix for
stable and this may not need to be backported. I would guess whoever
cares about mprotect() won't care 1G dax puds yet, vice versa. I hope
fixing that in new kernels would be fine, but I'm open to suggestions.
There are a few small things changed to teach mprotect work on PUDs. E.g.
it will need to start with dropping NUMA_HUGE_PTE_UPDATES which may stop
making sense when there can be more than one type of huge pte. OTOH,
we'll also need to push the mmu notifiers from pmd to pud layers, which
might need some attention but so far I think it's safe. For such details,
please refer to each patch's commit message.
The mprotect() pud process should be straightforward, as I kept it as
simple as possible. There's no NUMA handled as dax simply doesn't support
that. There's also no userfault involvements as file memory (even if work
with userfault-wp async mode) will need to split a pud, so pud entry
doesn't need to yet know userfault's existance (but hugetlb entries will;
that's also for later).
This patch (of 7):
Currently the dax fault handler dumps the vma range when dynamic debugging
enabled. That's mostly not useful. Dump the (aligned) address instead
with the order info.
Link: https://lkml.kernel.org/r/20240807194812.819412-1-peterx@xxxxxxxxxx
Link: https://lkml.kernel.org/r/20240807194812.819412-2-peterx@xxxxxxxxxx
Signed-off-by: Peter Xu <peterx@xxxxxxxxxx>
Acked-by: David Hildenbrand <david@xxxxxxxxxx>
Cc: Aneesh Kumar K.V <aneesh.kumar@xxxxxxxxxxxxx>
Cc: Borislav Petkov <bp@xxxxxxxxx>
Cc: Christophe Leroy <christophe.leroy@xxxxxxxxxx>
Cc: Dan Williams <dan.j.williams@xxxxxxxxx>
Cc: Dave Hansen <dave.hansen@xxxxxxxxxxxxxxx>
Cc: Dave Jiang <dave.jiang@xxxxxxxxx>
Cc: David Rientjes <rientjes@xxxxxxxxxx>
Cc: "Edgecombe, Rick P" <rick.p.edgecombe@xxxxxxxxx>
Cc: "Huang, Ying" <ying.huang@xxxxxxxxx>
Cc: Hugh Dickins <hughd@xxxxxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxxxxx>
Cc: James Houghton <jthoughton@xxxxxxxxxx>
Cc: Kirill A. Shutemov <kirill@xxxxxxxxxxxxx>
Cc: Matthew Wilcox <willy@xxxxxxxxxxxxx>
Cc: Mel Gorman <mgorman@xxxxxxxxxxxxxxxxxxx>
Cc: Michael Ellerman <mpe@xxxxxxxxxxxxxx>
Cc: Nicholas Piggin <npiggin@xxxxxxxxx>
Cc: Oscar Salvador <osalvador@xxxxxxx>
Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx>
Cc: Rik van Riel <riel@xxxxxxxxxxx>
Cc: Sean Christopherson <seanjc@xxxxxxxxxx>
Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Cc: Vlastimil Babka <vbabka@xxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
drivers/dax/device.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--- a/drivers/dax/device.c~mm-dax-dump-start-address-in-fault-handler
+++ a/drivers/dax/device.c
@@ -235,9 +235,9 @@ static vm_fault_t dev_dax_huge_fault(str
int id;
struct dev_dax *dev_dax = filp->private_data;
- dev_dbg(&dev_dax->dev, "%s: %s (%#lx - %#lx) order:%d\n", current->comm,
- (vmf->flags & FAULT_FLAG_WRITE) ? "write" : "read",
- vmf->vma->vm_start, vmf->vma->vm_end, order);
+ dev_dbg(&dev_dax->dev, "%s: op=%s addr=%#lx order=%d\n", current->comm,
+ (vmf->flags & FAULT_FLAG_WRITE) ? "write" : "read",
+ vmf->address & ~((1UL << (order + PAGE_SHIFT)) - 1), order);
id = dax_read_lock();
if (order == 0)
_
Patches currently in -mm which might be from peterx@xxxxxxxxxx are
mm-mprotect-push-mmu-notifier-to-puds.patch
mm-powerpc-add-missing-pud-helpers.patch
mm-x86-make-pud_leaf-only-care-about-pse-bit.patch
mm-x86-arch_check_zapped_pud.patch
mm-x86-add-missing-pud-helpers.patch
mm-mprotect-fix-dax-pud-handlings.patch
