FAILED: patch "[PATCH] arch/arm/mm: fix major fault accounting when retrying under" failed to apply to 6.7-stable tree

FAILED: patch "[PATCH] arch/arm/mm: fix major fault accounting when retrying under" failed to apply to 6.7-stable tree

[gregkh]

The 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 <stable@vger.kernel.org>.

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 '<stable@vger.kernel.org>' --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 <surenb@google.com>
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/20231006195318.4087158-6-willy@infradead.org/
[3] https://lore.kernel.org/all/20231226214610.109282-1-surenb@google.com/

Link: https://lkml.kernel.org/r/20240123064305.2829244-1-surenb@google.com
Fixes: 12214eba1992 ("mm: handle read faults under the VMA lock")
Reported-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index e96fb40b9cc3..07565b593ed6 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -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 6.7.y] arch/arm/mm: fix major fault accounting when retrying under per-VMA lock

[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/20231006195318.4087158-6-willy@infradead.org/
[3] https://lore.kernel.org/all/20231226214610.109282-1-surenb@google.com/

Link: https://lkml.kernel.org/r/20240123064305.2829244-1-surenb@google.com
Fixes: 12214eba1992 ("mm: handle read faults under the VMA lock")
Reported-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
 arch/arm/mm/fault.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index e96fb40b9cc3..07565b593ed6 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -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

[Suren Baghdasaryan]

From: Wang Kefeng <wangkefeng.wang@huawei.com>

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.

Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
---
 arch/arm/Kconfig    |  1 +
 arch/arm/mm/fault.c | 30 ++++++++++++++++++++++++++++++
 2 files changed, 31 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index f8567e95f98b..8f47d6762ea4 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -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
diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index fef62e4a9edd..e96fb40b9cc3 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -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
-- 
2.44.0.rc0.258.g7320e95886-goog

[PATCH 2/2] arch/arm/mm: fix major fault accounting when retrying under per-VMA lock

[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/20231006195318.4087158-6-willy@infradead.org/
[3] https://lore.kernel.org/all/20231226214610.109282-1-surenb@google.com/

Link: https://lkml.kernel.org/r/20240123064305.2829244-1-surenb@google.com
Fixes: 12214eba1992 ("mm: handle read faults under the VMA lock")
Reported-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
Cc: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Will Deacon <will@kernel.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
 arch/arm/mm/fault.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
index e96fb40b9cc3..07565b593ed6 100644
--- a/arch/arm/mm/fault.c
+++ b/arch/arm/mm/fault.c
@@ -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

Re: [PATCH 6.7.y] arch/arm/mm: fix major fault accounting when retrying under per-VMA lock

[Suren Baghdasaryan]

On Tue, Feb 20, 2024 at 11:02 AM Suren Baghdasaryan <surenb@google.com> wrote:
>
> 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/20231006195318.4087158-6-willy@infradead.org/
> [3] https://lore.kernel.org/all/20231226214610.109282-1-surenb@google.com/
>
> Link: https://lkml.kernel.org/r/20240123064305.2829244-1-surenb@google.com
> Fixes: 12214eba1992 ("mm: handle read faults under the VMA lock")
> Reported-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> Cc: Alexander Gordeev <agordeev@linux.ibm.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
> Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Will Deacon <will@kernel.org>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

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/20240220190351.39815-1-surenb@google.com/
https://lore.kernel.org/all/20240220190351.39815-2-surenb@google.com/

Thanks,
Suren.

> ---
>  arch/arm/mm/fault.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/arch/arm/mm/fault.c b/arch/arm/mm/fault.c
> index e96fb40b9cc3..07565b593ed6 100644
> --- a/arch/arm/mm/fault.c
> +++ b/arch/arm/mm/fault.c
> @@ -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
>

Re: [PATCH 1/2] ARM: 9328/1: mm: try VMA lock-based page fault handling first

[Greg KH]

On Tue, Feb 20, 2024 at 11:03:50AM -0800, Suren Baghdasaryan wrote:
> From: Wang Kefeng <wangkefeng.wang@huawei.com>
> 
> 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.
> 
> Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> ---
>  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 2/2] arch/arm/mm: fix major fault accounting when retrying under per-VMA lock

[Greg KH]

On Tue, Feb 20, 2024 at 11:03:51AM -0800, Suren Baghdasaryan wrote:
> 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/20231006195318.4087158-6-willy@infradead.org/
> [3] https://lore.kernel.org/all/20231226214610.109282-1-surenb@google.com/
> 
> Link: https://lkml.kernel.org/r/20240123064305.2829244-1-surenb@google.com
> Fixes: 12214eba1992 ("mm: handle read faults under the VMA lock")
> Reported-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> Cc: Alexander Gordeev <agordeev@linux.ibm.com>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Catalin Marinas <catalin.marinas@arm.com>
> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
> Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Palmer Dabbelt <palmer@dabbelt.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Will Deacon <will@kernel.org>
> Cc: <stable@vger.kernel.org>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
> ---
>  arch/arm/mm/fault.c | 2 ++
>  1 file changed, 2 insertions(+)

No git id?  :(

Re: [PATCH 1/2] ARM: 9328/1: mm: try VMA lock-based page fault handling first

[Suren Baghdasaryan]

On Tue, Feb 20, 2024 at 12:20 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Feb 20, 2024 at 11:03:50AM -0800, Suren Baghdasaryan wrote:
> > From: Wang Kefeng <wangkefeng.wang@huawei.com>
> >
> > 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.
> >
> > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> > Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> > ---
> >  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,

Sorry, I used the command from your earlier email about the merge conflict:
git send-email --to '<stable@vger.kernel.org>' --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?

>
> greg k-h

Re: [PATCH 1/2] ARM: 9328/1: mm: try VMA lock-based page fault handling first

[Greg KH]

On Tue, Feb 20, 2024 at 12:23:01PM -0800, Suren Baghdasaryan wrote:
> On Tue, Feb 20, 2024 at 12:20 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> >
> > On Tue, Feb 20, 2024 at 11:03:50AM -0800, Suren Baghdasaryan wrote:
> > > From: Wang Kefeng <wangkefeng.wang@huawei.com>
> > >
> > > 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.
> > >
> > > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> > > Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> > > ---
> > >  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,
> 
> Sorry, I used the command from your earlier email about the merge conflict:
> git send-email --to '<stable@vger.kernel.org>' --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

[Suren Baghdasaryan]

On Tue, Feb 20, 2024 at 12:46 PM Greg KH <gregkh@linuxfoundation.org> wrote:
>
> On Tue, Feb 20, 2024 at 12:23:01PM -0800, Suren Baghdasaryan wrote:
> > On Tue, Feb 20, 2024 at 12:20 PM Greg KH <gregkh@linuxfoundation.org> wrote:
> > >
> > > On Tue, Feb 20, 2024 at 11:03:50AM -0800, Suren Baghdasaryan wrote:
> > > > From: Wang Kefeng <wangkefeng.wang@huawei.com>
> > > >
> > > > 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.
> > > >
> > > > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> > > > Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
> > > > Signed-off-by: Suren Baghdasaryan <surenb@google.com>
> > > > ---
> > > >  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,
> >
> > Sorry, I used the command from your earlier email about the merge conflict:
> > git send-email --to '<stable@vger.kernel.org>' --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 :(

Ah, I see. Will do next time.

>
>
> And the subject prefix didn't work here, right?

Yes, looks like it. It worked the first time though :/

>
> thanks,
>
> greg k-h