FAILED: patch "[PATCH] arch/arm/mm: fix major fault accounting when retrying under" failed to apply to 6.7-stable tree
Subsystems (2)
[email protected]
maintainerThe patch below does not apply to the 6.7-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.7.y
git checkout FETCH_HEAD
git cherry-pick -x e870920bbe68e52335a4c31a059e6af6a9a59dbb
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2024021921-bleak-sputter-5ecf@gregkh' --subject-prefix 'PATCH 6.7.y' HEAD^..
Possible dependencies:
e870920bbe68 ("arch/arm/mm: fix major fault accounting when retrying under per-VMA lock") c16af1212479 ("ARM: 9328/1: mm: try VMA lock-based page fault handling first")
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From e870920bbe68e52335a4c31a059e6af6a9a59dbb Mon Sep 17 00:00:00 2001
From: Suren Baghdasaryan <[email protected]>
Date: Mon, 22 Jan 2024 22:43:05 -0800
Subject: [PATCH] arch/arm/mm: fix major fault accounting when retrying under
per-VMA lock
The change [1] missed ARM architecture when fixing major fault accounting for page fault retry under per-VMA lock.
The user-visible effects is that it restores correct major fault accounting that was broken after [2] was merged in 6.7 kernel. The more detailed description is in [3] and this patch simply adds the same fix to ARM architecture which I missed in [3].
Add missing code to fix ARM architecture fault accounting.
[1] 46e714c729c8 ("arch/mm/fault: fix major fault accounting when retrying under per-VMA lock")
[2] https://lore.kernel.org/all/[email protected]/
[3] https://lore.kernel.org/all/[email protected]/
arch/arm/mm/fault.c +2 -0
@@ -298,6 +298,8 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs) goto done; }count_vm_vma_lock_event (VMA_LOCK_RETRY ); +if (fault &VM_FAULT_MAJOR ) + flags |=FAULT_FLAG_TRIED ;/* Quick path to respond to signals */ if (fault_signal_pending (fault, regs)) {
PATCH 1/1 arch/arm/mm: fix major fault accounting when retrying under per-VMA lock
The change [1] missed ARM architecture when fixing major fault accounting for page fault retry under per-VMA lock.
The user-visible effects is that it restores correct major fault accounting that was broken after [2] was merged in 6.7 kernel. The more detailed description is in [3] and this patch simply adds the same fix to ARM architecture which I missed in [3].
Add missing code to fix ARM architecture fault accounting.
[1] 46e714c729c8 ("arch/mm/fault: fix major fault accounting when retrying under per-VMA lock")
[2] https://lore.kernel.org/all/[email protected]/
[3] https://lore.kernel.org/all/[email protected]/
--- arch/arm/mm/fault.c | 2 ++ 1 file changed, 2 insertions(+)
arch/arm/mm/fault.c +2 -0
@@ -298,6 +298,8 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs) goto done; }count_vm_vma_lock_event (VMA_LOCK_RETRY ); +if (fault &VM_FAULT_MAJOR ) + flags |=FAULT_FLAG_TRIED ;/* Quick path to respond to signals */ if (fault_signal_pending (fault, regs)) {
Signature · 1 line
2.44.0.rc0.258.g7320e95886-goog
Re: [PATCH 6.7.y] arch/arm/mm: fix major fault accounting when retrying under per-VMA lock
Quoted 24 lines · Suren Baghdasaryan
The change [1] missed ARM architecture when fixing major fault accounting for page fault retry under per-VMA lock.
The user-visible effects is that it restores correct major fault accounting that was broken after [2] was merged in 6.7 kernel. The more detailed description is in [3] and this patch simply adds the same fix to ARM architecture which I missed in [3].
Add missing code to fix ARM architecture fault accounting.
[1]
46e714c729c8("arch/mm/fault: fix major fault accounting when retrying under per-VMA lock")
[2] https://lore.kernel.org/all/[email protected]/
[3] https://lore.kernel.org/all/[email protected]/Fixes 12214eba1992 ("mm: handle read faults under the VMA lock")Reported-by Russell King (Oracle) <[email protected]>Signed-off-by Suren Baghdasaryan <[email protected]>Cc Alexander Gordeev <[email protected]>Cc Andy Lutomirski <[email protected]>Cc Catalin Marinas <[email protected]>Cc Christophe Leroy <[email protected]>Cc Dave Hansen <[email protected]>
Quoted 8 lines
Cc Gerald Schaefer <[email protected]>Cc Matthew Wilcox (Oracle) <[email protected]>Cc Michael Ellerman <[email protected]>Cc Palmer Dabbelt <[email protected]>Cc Peter Zijlstra <[email protected]>Cc Will Deacon <[email protected]>Cc <[email protected]>Signed-off-by Andrew Morton <[email protected]>
Sorry, missed the prerequisite patch. Please ignore this one and see the next patchset I sent with 2 patches in it:
https://lore.kernel.org/all/[email protected]/
https://lore.kernel.org/all/[email protected]/
Thanks,
Suren.
Quoted 20 lines
--- arch/arm/mm/fault.c | 2 ++ 1 file changed, 2 insertions(+)arch/arm/mm/fault.c +2
-1@@ -298,6 +298,8 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs) goto done; }count_vm_vma_lock_event (VMA_LOCK_RETRY ); +if (fault &VM_FAULT_MAJOR ) + flags |=FAULT_FLAG_TRIED ;/* Quick path to respond to signals */ if (fault_signal_pending (fault, regs)) { --2.44.0.rc0.258.g7320e95886-goog
PATCH 1/2 ARM: 9328/1: mm: try VMA lock-based page fault handling first
In reply to [email protected]From: Wang Kefeng <[email protected]>
Attempt VMA lock-based page fault handling first, and fall back to the existing mmap_lock-based handling if that fails, the ebizzy benchmark shows 25% improvement on qemu with 2 cpus.
--- arch/arm/Kconfig | 1 + arch/arm/mm/fault.c | 30 ++++++++++++++++++++++++++++++ 2 files changed, 31 insertions(+)
arch/arm/Kconfig +1 -0
@@ -35,6 +35,7 @@ config ARM select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT if CPU_V7 select ARCH_SUPPORTS_ATOMIC_RMW select ARCH_SUPPORTS_HUGETLBFS if ARM_LPAE + select ARCH_SUPPORTS_PER_VMA_LOCK select ARCH_USE_BUILTIN_BSWAP select ARCH_USE_CMPXCHG_LOCKREF select ARCH_USE_MEMTEST
arch/arm/mm/fault.c +30 -0
@@ -278,6 +278,35 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs)perf_sw_event (PERF_COUNT_SW_PAGE_FAULTS ,1 , regs, addr); +if (!(flags &FAULT_FLAG_USER )) + goto lock_mmap; + + vma =lock_vma_under_rcu (mm, addr); +if (!vma) + goto lock_mmap; + +if (!(vma->vm_flags & vm_flags)) { +vma_end_read (vma); + goto lock_mmap; + } + fault =handle_mm_fault (vma, addr, flags |FAULT_FLAG_VMA_LOCK , regs); +if (!(fault & (VM_FAULT_RETRY |VM_FAULT_COMPLETED ))) +vma_end_read (vma); + +if (!(fault &VM_FAULT_RETRY )) { +count_vm_vma_lock_event (VMA_LOCK_SUCCESS ); + goto done; + } +count_vm_vma_lock_event (VMA_LOCK_RETRY ); + +/* Quick path to respond to signals */ +if (fault_signal_pending (fault, regs)) { +if (!user_mode (regs)) + goto no_context; +return 0 ; + } +lock_mmap: + retry: vma =lock_mm_and_find_vma (mm, addr, regs);if (unlikely (!vma)) {
@@ -316,6 +345,7 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs) }mmap_read_unlock (mm); +done:/* * Handle the "normal" case first - VM_FAULT_MAJOR
Signature · 1 line
2.44.0.rc0.258.g7320e95886-goog
PATCH 2/2 arch/arm/mm: fix major fault accounting when retrying under per-VMA lock
The change [1] missed ARM architecture when fixing major fault accounting for page fault retry under per-VMA lock.
The user-visible effects is that it restores correct major fault accounting that was broken after [2] was merged in 6.7 kernel. The more detailed description is in [3] and this patch simply adds the same fix to ARM architecture which I missed in [3].
Add missing code to fix ARM architecture fault accounting.
[1] 46e714c729c8 ("arch/mm/fault: fix major fault accounting when retrying under per-VMA lock")
[2] https://lore.kernel.org/all/[email protected]/
[3] https://lore.kernel.org/all/[email protected]/
--- arch/arm/mm/fault.c | 2 ++ 1 file changed, 2 insertions(+)
arch/arm/mm/fault.c +2 -0
@@ -298,6 +298,8 @@ do_page_fault(unsigned long addr, unsigned int fsr, struct pt_regs *regs) goto done; }count_vm_vma_lock_event (VMA_LOCK_RETRY ); +if (fault &VM_FAULT_MAJOR ) + flags |=FAULT_FLAG_TRIED ;/* Quick path to respond to signals */ if (fault_signal_pending (fault, regs)) {
Signature · 1 line
2.44.0.rc0.258.g7320e95886-goog
Greg KH
maintainerRe: [PATCH 2/2] arch/arm/mm: fix major fault accounting when retrying under per-VMA lock
Quoted 31 lines · Suren Baghdasaryan
The change [1] missed ARM architecture when fixing major fault accounting for page fault retry under per-VMA lock.
The user-visible effects is that it restores correct major fault accounting that was broken after [2] was merged in 6.7 kernel. The more detailed description is in [3] and this patch simply adds the same fix to ARM architecture which I missed in [3].
Add missing code to fix ARM architecture fault accounting.
[1]
46e714c729c8("arch/mm/fault: fix major fault accounting when retrying under per-VMA lock")
[2] https://lore.kernel.org/all/[email protected]/
[3] https://lore.kernel.org/all/[email protected]/Fixes 12214eba1992 ("mm: handle read faults under the VMA lock")Reported-by Russell King (Oracle) <[email protected]>Signed-off-by Suren Baghdasaryan <[email protected]>Cc Alexander Gordeev <[email protected]>Cc Andy Lutomirski <[email protected]>Cc Catalin Marinas <[email protected]>Cc Christophe Leroy <[email protected]>Cc Dave Hansen <[email protected]>Cc Gerald Schaefer <[email protected]>Cc Matthew Wilcox (Oracle) <[email protected]>Cc Michael Ellerman <[email protected]>Cc Palmer Dabbelt <[email protected]>Cc Peter Zijlstra <[email protected]>Cc Will Deacon <[email protected]>Cc <[email protected]>Signed-off-by Andrew Morton <[email protected]>
Quoted 3 lines
--- arch/arm/mm/fault.c | 2 ++ 1 file changed, 2 insertions(+)
No git id? :(
Greg KH
maintainerRe: [PATCH 1/2] ARM: 9328/1: mm: try VMA lock-based page fault handling first
In reply to Suren BaghdasaryanQuoted 6 lines · Suren Baghdasaryan
From: Wang Kefeng <[email protected]>
Attempt VMA lock-based page fault handling first, and fall back to the existing mmap_lock-based handling if that fails, the ebizzy benchmark shows 25% improvement on qemu with 2 cpus.
Quoted 7 lines
Signed-off-by Kefeng Wang <[email protected]>Signed-off-by Russell King (Oracle) <[email protected]>Signed-off-by Suren Baghdasaryan <[email protected]>--- arch/arm/Kconfig | 1 + arch/arm/mm/fault.c | 30 ++++++++++++++++++++++++++++++ 2 files changed, 31 insertions(+)
No git id?
What kernel branch(s) does this go to?
confused,
greg k-h
Re: [PATCH 1/2] ARM: 9328/1: mm: try VMA lock-based page fault handling first
Quoted 16 lines · Greg KH
Quoted 6 lines · Suren Baghdasaryan
From: Wang Kefeng <[email protected]>
Attempt VMA lock-based page fault handling first, and fall back to the existing mmap_lock-based handling if that fails, the ebizzy benchmark shows 25% improvement on qemu with 2 cpus.
Quoted 7 lines
Signed-off-by Kefeng Wang <[email protected]>Signed-off-by Russell King (Oracle) <[email protected]>Signed-off-by Suren Baghdasaryan <[email protected]>--- arch/arm/Kconfig | 1 + arch/arm/mm/fault.c | 30 ++++++++++++++++++++++++++++++ 2 files changed, 31 insertions(+)
Quoted 5 lines
No git id?
What kernel branch(s) does this go to?
confused,
Sorry, I used the command from your earlier email about the merge conflict:
git send-email --to '<[email protected]>' --in-reply-to '2024021921-bleak-sputter-5ecf@gregkh' --subject-prefix 'PATCH 6.7.y' HEAD^..
but it didn't send both patches, so I formatted the patches I wanted to send and sent it with the same command replacing "HEAD^.." with "*.patch". What should I have done instead?
Quoted 2 lines
greg k-h
Greg KH
maintainerRe: [PATCH 1/2] ARM: 9328/1: mm: try VMA lock-based page fault handling first
Quoted 23 lines · Suren Baghdasaryan
Quoted 16 lines · Greg KH
Quoted 6 lines · Suren Baghdasaryan
From: Wang Kefeng <[email protected]>
Attempt VMA lock-based page fault handling first, and fall back to the existing mmap_lock-based handling if that fails, the ebizzy benchmark shows 25% improvement on qemu with 2 cpus.
Quoted 7 lines
Signed-off-by Kefeng Wang <[email protected]>Signed-off-by Russell King (Oracle) <[email protected]>Signed-off-by Suren Baghdasaryan <[email protected]>--- arch/arm/Kconfig | 1 + arch/arm/mm/fault.c | 30 ++++++++++++++++++++++++++++++ 2 files changed, 31 insertions(+)Quoted 5 lines
No git id?
What kernel branch(s) does this go to?
confused,
Quoted 7 lines
Sorry, I used the command from your earlier email about the merge conflict:
git send-email --to '<[email protected]>' --in-reply-to '2024021921-bleak-sputter-5ecf@gregkh' --subject-prefix 'PATCH 6.7.y' HEAD^..
but it didn't send both patches, so I formatted the patches I wanted to send and sent it with the same command replacing "HEAD^.." with "*.patch". What should I have done instead?
You forgot the "git cherry-pick -x " portion of the instructions :(
And the subject prefix didn't work here, right?
thanks,
greg k-h
Re: [PATCH 1/2] ARM: 9328/1: mm: try VMA lock-based page fault handling first
Quoted 33 lines · Greg KH
Quoted 23 lines · Suren Baghdasaryan
Quoted 16 lines · Greg KH
Quoted 6 lines · Suren Baghdasaryan
From: Wang Kefeng <[email protected]>
Attempt VMA lock-based page fault handling first, and fall back to the existing mmap_lock-based handling if that fails, the ebizzy benchmark shows 25% improvement on qemu with 2 cpus.
Quoted 7 lines
Signed-off-by Kefeng Wang <[email protected]>Signed-off-by Russell King (Oracle) <[email protected]>Signed-off-by Suren Baghdasaryan <[email protected]>--- arch/arm/Kconfig | 1 + arch/arm/mm/fault.c | 30 ++++++++++++++++++++++++++++++ 2 files changed, 31 insertions(+)Quoted 5 lines
No git id?
What kernel branch(s) does this go to?
confused,
Quoted 7 lines
Sorry, I used the command from your earlier email about the merge conflict:
git send-email --to '<[email protected]>' --in-reply-to '2024021921-bleak-sputter-5ecf@gregkh' --subject-prefix 'PATCH 6.7.y' HEAD^..
but it didn't send both patches, so I formatted the patches I wanted to send and sent it with the same command replacing "HEAD^.." with "*.patch". What should I have done instead?
Quoted 1 line
You forgot the "git cherry-pick -x " portion of the instructions :(
Ah, I see. Will do next time.
Quoted 3 lines
And the subject prefix didn't work here, right?
Yes, looks like it. It worked the first time though :/
Quoted 4 lines
thanks,
greg k-h