4.14-stable patches

added patches:
	forcedeth-fix-an-error-handling-path-in-nv_probe.patch
	x86-show_trace_log_lvl-ensure-stack-pointer-is-aligned-again.patch

diff --git a/queue-4.14/forcedeth-fix-an-error-handling-path-in-nv_probe.patch b/queue-4.14/forcedeth-fix-an-error-handling-path-in-nv_probe.patch
new file mode 100644 (file)
index 0000000..49be22b
--- /dev/null
+++ b/queue-4.14/forcedeth-fix-an-error-handling-path-in-nv_probe.patch
@@ -0,0 +1,35 @@
+From 5b17a4971d3b2a073f4078dd65331efbe35baa2d Mon Sep 17 00:00:00 2001
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Date: Sat, 20 May 2023 10:30:17 +0200
+Subject: forcedeth: Fix an error handling path in nv_probe()
+
+From: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+
+commit 5b17a4971d3b2a073f4078dd65331efbe35baa2d upstream.
+
+If an error occures after calling nv_mgmt_acquire_sema(), it should be
+undone with a corresponding nv_mgmt_release_sema() call.
+
+Add it in the error handling path of the probe as already done in the
+remove function.
+
+Fixes: cac1c52c3621 ("forcedeth: mgmt unit interface")
+Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
+Acked-by: Zhu Yanjun <zyjzyj2000@gmail.com>
+Link: https://lore.kernel.org/r/355e9a7d351b32ad897251b6f81b5886fcdc6766.1684571393.git.christophe.jaillet@wanadoo.fr
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/nvidia/forcedeth.c |    1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/net/ethernet/nvidia/forcedeth.c
++++ b/drivers/net/ethernet/nvidia/forcedeth.c
+@@ -6020,6 +6020,7 @@ static int nv_probe(struct pci_dev *pci_
+       return 0;
+ 
+ out_error:
++      nv_mgmt_release_sema(dev);
+       if (phystate_orig)
+               writel(phystate|NVREG_ADAPTCTL_RUNNING, base + NvRegAdapterControl);
+ out_freering:

diff --git a/queue-4.14/series b/queue-4.14/series
index 3c6705660c2ffb0676b63178e29a01f6e66be3a4..2fae2392689c4566659c07bc90cd7dd3eefeadbc 100644 (file)
--- a/queue-4.14/series
+++ b/queue-4.14/series
@@ -81,3 +81,5 @@ power-supply-bq27xxx-fix-i2c-irq-race-on-remove.patch
 power-supply-bq27xxx-fix-poll_interval-handling-and-races-on-remove.patch
 power-supply-sbs-charger-fix-inhibited-bit-for-status-reg.patch
 xen-pvcalls-back-fix-double-frees-with-pvcalls_new_active_socket.patch
+x86-show_trace_log_lvl-ensure-stack-pointer-is-aligned-again.patch
+forcedeth-fix-an-error-handling-path-in-nv_probe.patch

diff --git a/queue-4.14/x86-show_trace_log_lvl-ensure-stack-pointer-is-aligned-again.patch b/queue-4.14/x86-show_trace_log_lvl-ensure-stack-pointer-is-aligned-again.patch
new file mode 100644 (file)
index 0000000..1f35446
--- /dev/null
+++ b/queue-4.14/x86-show_trace_log_lvl-ensure-stack-pointer-is-aligned-again.patch
@@ -0,0 +1,69 @@
+From 2e4be0d011f21593c6b316806779ba1eba2cd7e0 Mon Sep 17 00:00:00 2001
+From: Vernon Lovejoy <vlovejoy@redhat.com>
+Date: Fri, 12 May 2023 12:42:32 +0200
+Subject: x86/show_trace_log_lvl: Ensure stack pointer is aligned, again
+
+From: Vernon Lovejoy <vlovejoy@redhat.com>
+
+commit 2e4be0d011f21593c6b316806779ba1eba2cd7e0 upstream.
+
+The commit e335bb51cc15 ("x86/unwind: Ensure stack pointer is aligned")
+tried to align the stack pointer in show_trace_log_lvl(), otherwise the
+"stack < stack_info.end" check can't guarantee that the last read does
+not go past the end of the stack.
+
+However, we have the same problem with the initial value of the stack
+pointer, it can also be unaligned. So without this patch this trivial
+kernel module
+
+       #include <linux/module.h>
+
+       static int init(void)
+       {
+               asm volatile("sub    $0x4,%rsp");
+               dump_stack();
+               asm volatile("add    $0x4,%rsp");
+
+               return -EAGAIN;
+       }
+
+       module_init(init);
+       MODULE_LICENSE("GPL");
+
+crashes the kernel.
+
+Fixes: e335bb51cc15 ("x86/unwind: Ensure stack pointer is aligned")
+Signed-off-by: Vernon Lovejoy <vlovejoy@redhat.com>
+Signed-off-by: Oleg Nesterov <oleg@redhat.com>
+Link: https://lore.kernel.org/r/20230512104232.GA10227@redhat.com
+Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/dumpstack.c |    7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+--- a/arch/x86/kernel/dumpstack.c
++++ b/arch/x86/kernel/dumpstack.c
+@@ -115,7 +115,6 @@ void show_trace_log_lvl(struct task_stru
+       printk("%sCall Trace:\n", log_lvl);
+ 
+       unwind_start(&state, task, regs, stack);
+-      stack = stack ? : get_stack_pointer(task, regs);
+       regs = unwind_get_entry_regs(&state, &partial);
+ 
+       /*
+@@ -134,9 +133,13 @@ void show_trace_log_lvl(struct task_stru
+        * - hardirq stack
+        * - entry stack
+        */
+-      for ( ; stack; stack = PTR_ALIGN(stack_info.next_sp, sizeof(long))) {
++      for (stack = stack ?: get_stack_pointer(task, regs);
++           stack;
++           stack = stack_info.next_sp) {
+               const char *stack_name;
+ 
++              stack = PTR_ALIGN(stack, sizeof(long));
++
+               if (get_stack_info(stack, task, &stack_info, &visit_mask)) {
+                       /*
+                        * We weren't on a valid stack.  It's possible that