--- /dev/null
+From 95109657471311601b98e71f03d0244f48dc61bb Mon Sep 17 00:00:00 2001
+From: Cezary Rojewski <cezary.rojewski@intel.com>
+Date: Fri, 19 May 2023 22:17:07 +0200
+Subject: ASoC: Intel: Skylake: Fix declaration of enum skl_ch_cfg
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Cezary Rojewski <cezary.rojewski@intel.com>
+
+commit 95109657471311601b98e71f03d0244f48dc61bb upstream.
+
+Constant 'C4_CHANNEL' does not exist on the firmware side. Value 0xC is
+reserved for 'C7_1' instead.
+
+Fixes: 04afbbbb1cba ("ASoC: Intel: Skylake: Update the topology interface structure")
+Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
+Signed-off-by: Amadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
+Link: https://lore.kernel.org/r/20230519201711.4073845-4-amadeuszx.slawinski@linux.intel.com
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ include/uapi/sound/skl-tplg-interface.h | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/include/uapi/sound/skl-tplg-interface.h
++++ b/include/uapi/sound/skl-tplg-interface.h
+@@ -66,7 +66,8 @@ enum skl_ch_cfg {
+ SKL_CH_CFG_DUAL_MONO = 9,
+ SKL_CH_CFG_I2S_DUAL_STEREO_0 = 10,
+ SKL_CH_CFG_I2S_DUAL_STEREO_1 = 11,
+- SKL_CH_CFG_4_CHANNEL = 12,
++ SKL_CH_CFG_7_1 = 12,
++ SKL_CH_CFG_4_CHANNEL = SKL_CH_CFG_7_1,
+ SKL_CH_CFG_INVALID
+ };
+
--- /dev/null
+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
+@@ -6099,6 +6099,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:
--- /dev/null
+From af87194352cad882d787d06fb7efa714acd95427 Mon Sep 17 00:00:00 2001
+From: Shay Drory <shayd@nvidia.com>
+Date: Tue, 2 May 2023 13:35:11 +0300
+Subject: net/mlx5: Devcom, fix error flow in mlx5_devcom_register_device
+
+From: Shay Drory <shayd@nvidia.com>
+
+commit af87194352cad882d787d06fb7efa714acd95427 upstream.
+
+In case devcom allocation is failed, mlx5 is always freeing the priv.
+However, this priv might have been allocated by a different thread,
+and freeing it might lead to use-after-free bugs.
+Fix it by freeing the priv only in case it was allocated by the
+running thread.
+
+Fixes: fadd59fc50d0 ("net/mlx5: Introduce inter-device communication mechanism")
+Signed-off-by: Shay Drory <shayd@nvidia.com>
+Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlx5/core/lib/devcom.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/mellanox/mlx5/core/lib/devcom.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/lib/devcom.c
+@@ -110,7 +110,8 @@ struct mlx5_devcom *mlx5_devcom_register
+ priv->devs[idx] = dev;
+ devcom = mlx5_devcom_alloc(priv, idx);
+ if (!devcom) {
+- kfree(priv);
++ if (new_priv)
++ kfree(priv);
+ return ERR_PTR(-ENOMEM);
+ }
+
--- /dev/null
+From a65735148e0328f80c0f72f9f8d2f609bfcf4aff Mon Sep 17 00:00:00 2001
+From: Roi Dayan <roid@nvidia.com>
+Date: Mon, 1 May 2023 14:37:56 +0300
+Subject: net/mlx5: Fix error message when failing to allocate device memory
+
+From: Roi Dayan <roid@nvidia.com>
+
+commit a65735148e0328f80c0f72f9f8d2f609bfcf4aff upstream.
+
+Fix spacing for the error and also the correct error code pointer.
+
+Fixes: c9b9dcb430b3 ("net/mlx5: Move device memory management to mlx5_core")
+Signed-off-by: Roi Dayan <roid@nvidia.com>
+Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlx5/core/main.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/mellanox/mlx5/core/main.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/main.c
+@@ -887,7 +887,7 @@ static int mlx5_init_once(struct mlx5_co
+
+ dev->dm = mlx5_dm_create(dev);
+ if (IS_ERR(dev->dm))
+- mlx5_core_warn(dev, "Failed to init device memory%d\n", err);
++ mlx5_core_warn(dev, "Failed to init device memory %ld\n", PTR_ERR(dev->dm));
+
+ dev->tracer = mlx5_fw_tracer_create(dev);
+ dev->hv_vhca = mlx5_hv_vhca_create(dev);
--- /dev/null
+From afbed3f74830163f9559579dee382cac3cff82da Mon Sep 17 00:00:00 2001
+From: Jakub Kicinski <kuba@kernel.org>
+Date: Tue, 16 May 2023 18:59:35 -0700
+Subject: net/mlx5e: do as little as possible in napi poll when budget is 0
+
+From: Jakub Kicinski <kuba@kernel.org>
+
+commit afbed3f74830163f9559579dee382cac3cff82da upstream.
+
+NAPI gets called with budget of 0 from netpoll, which has interrupts
+disabled. We should try to free some space on Tx rings and nothing
+else.
+
+Specifically do not try to handle XDP TX or try to refill Rx buffers -
+we can't use the page pool from IRQ context. Don't check if IRQs moved,
+either, that makes no sense in netpoll. Netpoll calls _all_ the rings
+from whatever CPU it happens to be invoked on.
+
+In general do as little as possible, the work quickly adds up when
+there's tens of rings to poll.
+
+The immediate stack trace I was seeing is:
+
+ __do_softirq+0xd1/0x2c0
+ __local_bh_enable_ip+0xc7/0x120
+ </IRQ>
+ <TASK>
+ page_pool_put_defragged_page+0x267/0x320
+ mlx5e_free_xdpsq_desc+0x99/0xd0
+ mlx5e_poll_xdpsq_cq+0x138/0x3b0
+ mlx5e_napi_poll+0xc3/0x8b0
+ netpoll_poll_dev+0xce/0x150
+
+AFAIU page pool takes a BH lock, releases it and since BH is now
+enabled tries to run softirqs.
+
+Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
+Fixes: 60bbf7eeef10 ("mlx5: use page_pool for xdp_return_frame call")
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Reviewed-by: Simon Horman <simon.horman@corigine.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c | 16 +++++++++-------
+ 1 file changed, 9 insertions(+), 7 deletions(-)
+
+--- a/drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/en_txrx.c
+@@ -126,20 +126,22 @@ int mlx5e_napi_poll(struct napi_struct *
+ for (i = 0; i < c->num_tc; i++)
+ busy |= mlx5e_poll_tx_cq(&c->sq[i].cq, budget);
+
++ /* budget=0 means we may be in IRQ context, do as little as possible */
++ if (unlikely(!budget))
++ goto out;
++
+ busy |= mlx5e_poll_xdpsq_cq(&c->xdpsq.cq);
+
+ if (c->xdp)
+ busy |= mlx5e_poll_xdpsq_cq(&c->rq_xdpsq.cq);
+
+- if (likely(budget)) { /* budget=0 means: don't poll rx rings */
+- if (xsk_open)
+- work_done = mlx5e_poll_rx_cq(&xskrq->cq, budget);
++ if (xsk_open)
++ work_done = mlx5e_poll_rx_cq(&xskrq->cq, budget);
+
+- if (likely(budget - work_done))
+- work_done += mlx5e_poll_rx_cq(&rq->cq, budget - work_done);
++ if (likely(budget - work_done))
++ work_done += mlx5e_poll_rx_cq(&rq->cq, budget - work_done);
+
+- busy |= work_done == budget;
+- }
++ busy |= work_done == budget;
+
+ mlx5e_poll_ico_cq(&c->icosq.cq);
+
power-supply-sbs-charger-fix-inhibited-bit-for-status-reg.patch
coresight-fix-signedness-bug-in-tmc_etr_buf_insert_barrier_packet.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
+asoc-intel-skylake-fix-declaration-of-enum-skl_ch_cfg.patch
+forcedeth-fix-an-error-handling-path-in-nv_probe.patch
+net-mlx5e-do-as-little-as-possible-in-napi-poll-when-budget-is-0.patch
+net-mlx5-fix-error-message-when-failing-to-allocate-device-memory.patch
+net-mlx5-devcom-fix-error-flow-in-mlx5_devcom_register_device.patch
--- /dev/null
+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
+@@ -171,7 +171,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);
+
+ /*
+@@ -190,9 +189,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
projects / thirdparty / kernel / stable-queue.git / commitdiff
