--- /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
+@@ -6129,6 +6129,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 c7dd225bc224726c22db08e680bf787f60ebdee3 Mon Sep 17 00:00:00 2001
+From: Yevgeny Kliteynik <kliteyn@nvidia.com>
+Date: Sun, 2 Apr 2023 17:14:10 +0300
+Subject: net/mlx5: DR, Check force-loopback RC QP capability independently from RoCE
+
+From: Yevgeny Kliteynik <kliteyn@nvidia.com>
+
+commit c7dd225bc224726c22db08e680bf787f60ebdee3 upstream.
+
+SW Steering uses RC QP for writing STEs to ICM. This writingis done in LB
+(loopback), and FL (force-loopback) QP is preferred for performance. FL is
+available when RoCE is enabled or disabled based on RoCE caps.
+This patch adds reading of FL capability from HCA caps in addition to the
+existing reading from RoCE caps, thus fixing the case where we didn't
+have loopback enabled when RoCE was disabled.
+
+Fixes: 7304d603a57a ("net/mlx5: DR, Add support for force-loopback QP")
+Signed-off-by: Itamar Gozlan <igozlan@nvidia.com>
+Signed-off-by: Yevgeny Kliteynik <kliteyn@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/steering/dr_cmd.c | 4 +++-
+ include/linux/mlx5/mlx5_ifc.h | 4 +++-
+ 2 files changed, 6 insertions(+), 2 deletions(-)
+
+--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_cmd.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_cmd.c
+@@ -117,6 +117,8 @@ int mlx5dr_cmd_query_device(struct mlx5_
+ caps->gvmi = MLX5_CAP_GEN(mdev, vhca_id);
+ caps->flex_protocols = MLX5_CAP_GEN(mdev, flex_parser_protocols);
+ caps->sw_format_ver = MLX5_CAP_GEN(mdev, steering_format_version);
++ caps->roce_caps.fl_rc_qp_when_roce_disabled =
++ MLX5_CAP_GEN(mdev, fl_rc_qp_when_roce_disabled);
+
+ if (MLX5_CAP_GEN(mdev, roce)) {
+ err = dr_cmd_query_nic_vport_roce_en(mdev, 0, &roce_en);
+@@ -124,7 +126,7 @@ int mlx5dr_cmd_query_device(struct mlx5_
+ return err;
+
+ caps->roce_caps.roce_en = roce_en;
+- caps->roce_caps.fl_rc_qp_when_roce_disabled =
++ caps->roce_caps.fl_rc_qp_when_roce_disabled |=
+ MLX5_CAP_ROCE(mdev, fl_rc_qp_when_roce_disabled);
+ caps->roce_caps.fl_rc_qp_when_roce_enabled =
+ MLX5_CAP_ROCE(mdev, fl_rc_qp_when_roce_enabled);
+--- a/include/linux/mlx5/mlx5_ifc.h
++++ b/include/linux/mlx5/mlx5_ifc.h
+@@ -1513,7 +1513,9 @@ struct mlx5_ifc_cmd_hca_cap_bits {
+ u8 rc[0x1];
+
+ u8 uar_4k[0x1];
+- u8 reserved_at_241[0x9];
++ u8 reserved_at_241[0x7];
++ u8 fl_rc_qp_when_roce_disabled[0x1];
++ u8 regexp_params[0x1];
+ u8 uar_sz[0x6];
+ u8 reserved_at_248[0x2];
+ u8 umem_uid_0[0x1];
--- /dev/null
+From 1e5daf5565b61a96e570865091589afc9156e3d3 Mon Sep 17 00:00:00 2001
+From: Erez Shitrit <erezsh@nvidia.com>
+Date: Thu, 9 Mar 2023 16:43:15 +0200
+Subject: net/mlx5: DR, Fix crc32 calculation to work on big-endian (BE) CPUs
+
+From: Erez Shitrit <erezsh@nvidia.com>
+
+commit 1e5daf5565b61a96e570865091589afc9156e3d3 upstream.
+
+When calculating crc for hash index we use the function crc32 that
+calculates for little-endian (LE) arch.
+Then we convert it to network endianness using htonl(), but it's wrong
+to do the conversion in BE archs since the crc32 value is already LE.
+
+The solution is to switch the bytes from the crc result for all types
+of arc.
+
+Fixes: 40416d8ede65 ("net/mlx5: DR, Replace CRC32 implementation to use kernel lib")
+Signed-off-by: Erez Shitrit <erezsh@nvidia.com>
+Reviewed-by: Alex Vesker <valex@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/steering/dr_ste.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+--- a/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_ste.c
++++ b/drivers/net/ethernet/mellanox/mlx5/core/steering/dr_ste.c
+@@ -15,7 +15,8 @@ static u32 dr_ste_crc32_calc(const void
+ {
+ u32 crc = crc32(0, input_data, length);
+
+- return (__force u32)htonl(crc);
++ return (__force u32)((crc >> 24) & 0xff) | ((crc << 8) & 0xff0000) |
++ ((crc >> 8) & 0xff00) | ((crc << 24) & 0xff000000);
+ }
+
+ bool mlx5dr_ste_supp_ttl_cs_recalc(struct mlx5dr_cmd_caps *caps)
--- /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
+@@ -903,7 +903,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
+@@ -150,20 +150,22 @@ int mlx5e_napi_poll(struct napi_struct *
+ }
+ }
+
++ /* 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);
+ if (mlx5e_poll_ico_cq(&c->async_icosq.cq))
--- /dev/null
+From 95e4b25192e9238fd2dbe85d96dd2f8fd1ce9d14 Mon Sep 17 00:00:00 2001
+From: Dan Carpenter <dan.carpenter@linaro.org>
+Date: Mon, 15 May 2023 13:32:37 +0300
+Subject: platform/mellanox: mlxbf-pmc: fix sscanf() error checking
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Dan Carpenter <dan.carpenter@linaro.org>
+
+commit 95e4b25192e9238fd2dbe85d96dd2f8fd1ce9d14 upstream.
+
+The sscanf() function never returns negatives. It returns the number of
+items successfully read.
+
+Fixes: 1a218d312e65 ("platform/mellanox: mlxbf-pmc: Add Mellanox BlueField PMC driver")
+Signed-off-by: Dan Carpenter <dan.carpenter@linaro.org>
+Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Link: https://lore.kernel.org/r/4ccdfd28-099b-40bf-8d77-ad4ea2e76b93@kili.mountain
+Reviewed-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Hans de Goede <hdegoede@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/mellanox/mlxbf-pmc.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/platform/mellanox/mlxbf-pmc.c b/drivers/platform/mellanox/mlxbf-pmc.c
+index c2c9b0d3244c..be967d797c28 100644
+--- a/drivers/platform/mellanox/mlxbf-pmc.c
++++ b/drivers/platform/mellanox/mlxbf-pmc.c
+@@ -1348,9 +1348,8 @@ static int mlxbf_pmc_map_counters(struct device *dev)
+
+ for (i = 0; i < pmc->total_blocks; ++i) {
+ if (strstr(pmc->block_name[i], "tile")) {
+- ret = sscanf(pmc->block_name[i], "tile%d", &tile_num);
+- if (ret < 0)
+- return ret;
++ if (sscanf(pmc->block_name[i], "tile%d", &tile_num) != 1)
++ return -EINVAL;
+
+ if (tile_num >= pmc->tile_count)
+ continue;
+--
+2.40.1
+
--- /dev/null
+From 6ca328e985cd995dfd1d5de44046e6074f853fbb Mon Sep 17 00:00:00 2001
+From: Xin Long <lucien.xin@gmail.com>
+Date: Thu, 18 May 2023 16:03:00 -0400
+Subject: sctp: fix an issue that plpmtu can never go to complete state
+
+From: Xin Long <lucien.xin@gmail.com>
+
+commit 6ca328e985cd995dfd1d5de44046e6074f853fbb upstream.
+
+When doing plpmtu probe, the probe size is growing every time when it
+receives the ACK during the Search state until the probe fails. When
+the failure occurs, pl.probe_high is set and it goes to the Complete
+state.
+
+However, if the link pmtu is huge, like 65535 in loopback_dev, the probe
+eventually keeps using SCTP_MAX_PLPMTU as the probe size and never fails.
+Because of that, pl.probe_high can not be set, and the plpmtu probe can
+never go to the Complete state.
+
+Fix it by setting pl.probe_high to SCTP_MAX_PLPMTU when the probe size
+grows to SCTP_MAX_PLPMTU in sctp_transport_pl_recv(). Also, not allow
+the probe size greater than SCTP_MAX_PLPMTU in the Complete state.
+
+Fixes: b87641aff9e7 ("sctp: do state transition when a probe succeeds on HB ACK recv path")
+Signed-off-by: Xin Long <lucien.xin@gmail.com>
+Signed-off-by: David S. Miller <davem@davemloft.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/sctp/transport.c | 11 +++++++----
+ 1 file changed, 7 insertions(+), 4 deletions(-)
+
+--- a/net/sctp/transport.c
++++ b/net/sctp/transport.c
+@@ -331,9 +331,12 @@ bool sctp_transport_pl_recv(struct sctp_
+ t->pl.probe_size += SCTP_PL_BIG_STEP;
+ } else if (t->pl.state == SCTP_PL_SEARCH) {
+ if (!t->pl.probe_high) {
+- t->pl.probe_size = min(t->pl.probe_size + SCTP_PL_BIG_STEP,
+- SCTP_MAX_PLPMTU);
+- return false;
++ if (t->pl.probe_size < SCTP_MAX_PLPMTU) {
++ t->pl.probe_size = min(t->pl.probe_size + SCTP_PL_BIG_STEP,
++ SCTP_MAX_PLPMTU);
++ return false;
++ }
++ t->pl.probe_high = SCTP_MAX_PLPMTU;
+ }
+ t->pl.probe_size += SCTP_PL_MIN_STEP;
+ if (t->pl.probe_size >= t->pl.probe_high) {
+@@ -348,7 +351,7 @@ bool sctp_transport_pl_recv(struct sctp_
+ } else if (t->pl.state == SCTP_PL_COMPLETE && t->pl.raise_count == 30) {
+ /* Raise probe_size again after 30 * interval in Search Complete */
+ t->pl.state = SCTP_PL_SEARCH; /* Search Complete -> Search */
+- t->pl.probe_size += SCTP_PL_MIN_STEP;
++ t->pl.probe_size = min(t->pl.probe_size + SCTP_PL_MIN_STEP, SCTP_MAX_PLPMTU);
+ }
+
+ return t->pl.state == SCTP_PL_COMPLETE;
regulator-pca9450-fix-buck2-enable_mask.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
+sctp-fix-an-issue-that-plpmtu-can-never-go-to-complete-state.patch
+forcedeth-fix-an-error-handling-path-in-nv_probe.patch
+platform-mellanox-mlxbf-pmc-fix-sscanf-error-checking.patch
+net-mlx5e-do-as-little-as-possible-in-napi-poll-when-budget-is-0.patch
+net-mlx5-dr-fix-crc32-calculation-to-work-on-big-endian-be-cpus.patch
+net-mlx5-dr-check-force-loopback-rc-qp-capability-independently-from-roce.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
+@@ -195,7 +195,6 @@ static void show_trace_log_lvl(struct ta
+ 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);
+
+ /*
+@@ -214,9 +213,13 @@ static void show_trace_log_lvl(struct ta
+ * - 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
