From: Greg Kroah-Hartman Date: Sun, 8 Oct 2023 05:36:04 +0000 (+0200) Subject: 6.5-stable patches X-Git-Tag: v4.14.327~47 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=03069006305a88894d438950518e4b064d146a01;p=thirdparty%2Fkernel%2Fstable-queue.git 6.5-stable patches added patches: dm-zoned-free-dmz-ddev-array-in-dmz_put_zoned_devices.patch gpio-aspeed-fix-the-gpio-number-passed-to-pinctrl_gpio_set_config.patch gpio-pxa-disable-pinctrl-calls-for-mmp_gpio.patch ib-mlx4-fix-the-size-of-a-buffer-in-add_port_entries.patch of-dynamic-fix-potential-memory-leak-in-of_changeset_action.patch parisc-fix-crash-with-nr_cpus-1-option.patch parisc-restore-__ldcw_align-for-pa-risc-2.0-processors.patch rdma-bnxt_re-fix-the-handling-of-control-path-response-data.patch rdma-cma-fix-truncation-compilation-warning-in-make_cma_ports.patch rdma-cma-initialize-ib_sa_multicast-structure-to-0-when-join.patch rdma-core-require-admin-capabilities-to-set-system-parameters.patch rdma-mlx5-fix-assigning-access-flags-to-cache-mkeys.patch rdma-mlx5-fix-mkey-cache-possible-deadlock-on-cleanup.patch rdma-mlx5-fix-mutex-unlocking-on-error-flow-for-steering-anchor-creation.patch rdma-mlx5-fix-null-string-error.patch rdma-siw-fix-connection-failure-handling.patch rdma-srp-do-not-call-scsi_done-from-srp_abort.patch rdma-uverbs-fix-typo-of-sizeof-argument.patch smb-use-kernel_connect-and-kernel_bind.patch --- diff --git a/queue-6.5/dm-zoned-free-dmz-ddev-array-in-dmz_put_zoned_devices.patch b/queue-6.5/dm-zoned-free-dmz-ddev-array-in-dmz_put_zoned_devices.patch new file mode 100644 index 00000000000..365c0d8e0ae --- /dev/null +++ b/queue-6.5/dm-zoned-free-dmz-ddev-array-in-dmz_put_zoned_devices.patch @@ -0,0 +1,72 @@ +From 9850ccd5dd88075b2b7fd28d96299d5535f58cc5 Mon Sep 17 00:00:00 2001 +From: Fedor Pchelkin +Date: Wed, 20 Sep 2023 13:51:16 +0300 +Subject: dm zoned: free dmz->ddev array in dmz_put_zoned_devices + +From: Fedor Pchelkin + +commit 9850ccd5dd88075b2b7fd28d96299d5535f58cc5 upstream. + +Commit 4dba12881f88 ("dm zoned: support arbitrary number of devices") +made the pointers to additional zoned devices to be stored in a +dynamically allocated dmz->ddev array. However, this array is not freed. + +Rename dmz_put_zoned_device to dmz_put_zoned_devices and fix it to +free the dmz->ddev array when cleaning up zoned device information. +Remove NULL assignment for all dmz->ddev elements and just free the +dmz->ddev array instead. + +Found by Linux Verification Center (linuxtesting.org). + +Fixes: 4dba12881f88 ("dm zoned: support arbitrary number of devices") +Cc: stable@vger.kernel.org +Signed-off-by: Fedor Pchelkin +Signed-off-by: Mike Snitzer +Signed-off-by: Greg Kroah-Hartman +--- + drivers/md/dm-zoned-target.c | 15 +++++++-------- + 1 file changed, 7 insertions(+), 8 deletions(-) + +--- a/drivers/md/dm-zoned-target.c ++++ b/drivers/md/dm-zoned-target.c +@@ -748,17 +748,16 @@ err: + /* + * Cleanup zoned device information. + */ +-static void dmz_put_zoned_device(struct dm_target *ti) ++static void dmz_put_zoned_devices(struct dm_target *ti) + { + struct dmz_target *dmz = ti->private; + int i; + +- for (i = 0; i < dmz->nr_ddevs; i++) { +- if (dmz->ddev[i]) { ++ for (i = 0; i < dmz->nr_ddevs; i++) ++ if (dmz->ddev[i]) + dm_put_device(ti, dmz->ddev[i]); +- dmz->ddev[i] = NULL; +- } +- } ++ ++ kfree(dmz->ddev); + } + + static int dmz_fixup_devices(struct dm_target *ti) +@@ -948,7 +947,7 @@ err_bio: + err_meta: + dmz_dtr_metadata(dmz->metadata); + err_dev: +- dmz_put_zoned_device(ti); ++ dmz_put_zoned_devices(ti); + err: + kfree(dmz->dev); + kfree(dmz); +@@ -978,7 +977,7 @@ static void dmz_dtr(struct dm_target *ti + + bioset_exit(&dmz->bio_set); + +- dmz_put_zoned_device(ti); ++ dmz_put_zoned_devices(ti); + + mutex_destroy(&dmz->chunk_lock); + diff --git a/queue-6.5/gpio-aspeed-fix-the-gpio-number-passed-to-pinctrl_gpio_set_config.patch b/queue-6.5/gpio-aspeed-fix-the-gpio-number-passed-to-pinctrl_gpio_set_config.patch new file mode 100644 index 00000000000..8c69a8143ad --- /dev/null +++ b/queue-6.5/gpio-aspeed-fix-the-gpio-number-passed-to-pinctrl_gpio_set_config.patch @@ -0,0 +1,33 @@ +From f9315f17bf778cb8079a29639419fcc8a41a3c84 Mon Sep 17 00:00:00 2001 +From: Bartosz Golaszewski +Date: Tue, 3 Oct 2023 09:39:26 +0200 +Subject: gpio: aspeed: fix the GPIO number passed to pinctrl_gpio_set_config() + +From: Bartosz Golaszewski + +commit f9315f17bf778cb8079a29639419fcc8a41a3c84 upstream. + +pinctrl_gpio_set_config() expects the GPIO number from the global GPIO +numberspace, not the controller-relative offset, which needs to be added +to the chip base. + +Fixes: 5ae4cb94b313 ("gpio: aspeed: Add debounce support") +Signed-off-by: Bartosz Golaszewski +Reviewed-by: Andy Shevchenko +Reviewed-by: Andrew Jeffery +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpio/gpio-aspeed.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/gpio/gpio-aspeed.c ++++ b/drivers/gpio/gpio-aspeed.c +@@ -973,7 +973,7 @@ static int aspeed_gpio_set_config(struct + else if (param == PIN_CONFIG_BIAS_DISABLE || + param == PIN_CONFIG_BIAS_PULL_DOWN || + param == PIN_CONFIG_DRIVE_STRENGTH) +- return pinctrl_gpio_set_config(offset, config); ++ return pinctrl_gpio_set_config(chip->base + offset, config); + else if (param == PIN_CONFIG_DRIVE_OPEN_DRAIN || + param == PIN_CONFIG_DRIVE_OPEN_SOURCE) + /* Return -ENOTSUPP to trigger emulation, as per datasheet */ diff --git a/queue-6.5/gpio-pxa-disable-pinctrl-calls-for-mmp_gpio.patch b/queue-6.5/gpio-pxa-disable-pinctrl-calls-for-mmp_gpio.patch new file mode 100644 index 00000000000..772851fc24e --- /dev/null +++ b/queue-6.5/gpio-pxa-disable-pinctrl-calls-for-mmp_gpio.patch @@ -0,0 +1,34 @@ +From f0575116507b981e6a810e78ce3c9040395b958b Mon Sep 17 00:00:00 2001 +From: =?UTF-8?q?Duje=20Mihanovi=C4=87?= +Date: Fri, 29 Sep 2023 17:41:57 +0200 +Subject: gpio: pxa: disable pinctrl calls for MMP_GPIO +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Duje Mihanović + +commit f0575116507b981e6a810e78ce3c9040395b958b upstream. + +Similarly to PXA3xx and MMP2, pinctrl-single isn't capable of setting +pin direction on MMP either. + +Fixes: a770d946371e ("gpio: pxa: add pin control gpio direction and request") +Signed-off-by: Duje Mihanović +Reviewed-by: Andy Shevchenko +Signed-off-by: Bartosz Golaszewski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/gpio/gpio-pxa.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/gpio/gpio-pxa.c ++++ b/drivers/gpio/gpio-pxa.c +@@ -238,6 +238,7 @@ static bool pxa_gpio_has_pinctrl(void) + switch (gpio_type) { + case PXA3XX_GPIO: + case MMP2_GPIO: ++ case MMP_GPIO: + return false; + + default: diff --git a/queue-6.5/ib-mlx4-fix-the-size-of-a-buffer-in-add_port_entries.patch b/queue-6.5/ib-mlx4-fix-the-size-of-a-buffer-in-add_port_entries.patch new file mode 100644 index 00000000000..023127e6839 --- /dev/null +++ b/queue-6.5/ib-mlx4-fix-the-size-of-a-buffer-in-add_port_entries.patch @@ -0,0 +1,51 @@ +From d7f393430a17c2bfcdf805462a5aa80be4285b27 Mon Sep 17 00:00:00 2001 +From: Christophe JAILLET +Date: Sat, 23 Sep 2023 07:55:56 +0200 +Subject: IB/mlx4: Fix the size of a buffer in add_port_entries() +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Christophe JAILLET + +commit d7f393430a17c2bfcdf805462a5aa80be4285b27 upstream. + +In order to be sure that 'buff' is never truncated, its size should be +12, not 11. + +When building with W=1, this fixes the following warnings: + + drivers/infiniband/hw/mlx4/sysfs.c: In function ‘add_port_entries’: + drivers/infiniband/hw/mlx4/sysfs.c:268:34: error: ‘sprintf’ may write a terminating nul past the end of the destination [-Werror=format-overflow=] + 268 | sprintf(buff, "%d", i); + | ^ + drivers/infiniband/hw/mlx4/sysfs.c:268:17: note: ‘sprintf’ output between 2 and 12 bytes into a destination of size 11 + 268 | sprintf(buff, "%d", i); + | ^~~~~~~~~~~~~~~~~~~~~~ + drivers/infiniband/hw/mlx4/sysfs.c:286:34: error: ‘sprintf’ may write a terminating nul past the end of the destination [-Werror=format-overflow=] + 286 | sprintf(buff, "%d", i); + | ^ + drivers/infiniband/hw/mlx4/sysfs.c:286:17: note: ‘sprintf’ output between 2 and 12 bytes into a destination of size 11 + 286 | sprintf(buff, "%d", i); + | ^~~~~~~~~~~~~~~~~~~~~~ + +Fixes: c1e7e466120b ("IB/mlx4: Add iov directory in sysfs under the ib device") +Signed-off-by: Christophe JAILLET +Link: https://lore.kernel.org/r/0bb1443eb47308bc9be30232cc23004c4d4cf43e.1695448530.git.christophe.jaillet@wanadoo.fr +Signed-off-by: Leon Romanovsky +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/hw/mlx4/sysfs.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/infiniband/hw/mlx4/sysfs.c ++++ b/drivers/infiniband/hw/mlx4/sysfs.c +@@ -223,7 +223,7 @@ void del_sysfs_port_mcg_attr(struct mlx4 + static int add_port_entries(struct mlx4_ib_dev *device, int port_num) + { + int i; +- char buff[11]; ++ char buff[12]; + struct mlx4_ib_iov_port *port = NULL; + int ret = 0 ; + struct ib_port_attr attr; diff --git a/queue-6.5/of-dynamic-fix-potential-memory-leak-in-of_changeset_action.patch b/queue-6.5/of-dynamic-fix-potential-memory-leak-in-of_changeset_action.patch new file mode 100644 index 00000000000..8c306ed42fd --- /dev/null +++ b/queue-6.5/of-dynamic-fix-potential-memory-leak-in-of_changeset_action.patch @@ -0,0 +1,51 @@ +From 55e95bfccf6db8d26a66c46e1de50d53c59a6774 Mon Sep 17 00:00:00 2001 +From: Dan Carpenter +Date: Fri, 8 Sep 2023 10:03:50 +0300 +Subject: of: dynamic: Fix potential memory leak in of_changeset_action() + +From: Dan Carpenter + +commit 55e95bfccf6db8d26a66c46e1de50d53c59a6774 upstream. + +Smatch complains that the error path where "action" is invalid leaks +the "ce" allocation: + drivers/of/dynamic.c:935 of_changeset_action() + warn: possible memory leak of 'ce' + +Fix this by doing the validation before the allocation. + +Note that there is not any actual problem with upstream kernels. All +callers of of_changeset_action() are static inlines with fixed action +values. + +Fixes: 914d9d831e61 ("of: dynamic: Refactor action prints to not use "%pOF" inside devtree_lock") +Reported-by: kernel test robot +Closes: https://lore.kernel.org/r/202309011059.EOdr4im9-lkp@intel.com/ +Signed-off-by: Dan Carpenter +Reviewed-by: Geert Uytterhoeven +Link: https://lore.kernel.org/r/7dfaf999-30ad-491c-9615-fb1138db121c@moroto.mountain +Signed-off-by: Rob Herring +Signed-off-by: Greg Kroah-Hartman +--- + drivers/of/dynamic.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/drivers/of/dynamic.c ++++ b/drivers/of/dynamic.c +@@ -927,13 +927,13 @@ int of_changeset_action(struct of_change + { + struct of_changeset_entry *ce; + ++ if (WARN_ON(action >= ARRAY_SIZE(action_names))) ++ return -EINVAL; ++ + ce = kzalloc(sizeof(*ce), GFP_KERNEL); + if (!ce) + return -ENOMEM; + +- if (WARN_ON(action >= ARRAY_SIZE(action_names))) +- return -EINVAL; +- + /* get a reference to the node */ + ce->action = action; + ce->np = of_node_get(np); diff --git a/queue-6.5/parisc-fix-crash-with-nr_cpus-1-option.patch b/queue-6.5/parisc-fix-crash-with-nr_cpus-1-option.patch new file mode 100644 index 00000000000..a2d37a8df74 --- /dev/null +++ b/queue-6.5/parisc-fix-crash-with-nr_cpus-1-option.patch @@ -0,0 +1,33 @@ +From d3b3c637e4eb8d3bbe53e5692aee66add72f9851 Mon Sep 17 00:00:00 2001 +From: Helge Deller +Date: Tue, 19 Sep 2023 15:26:35 +0200 +Subject: parisc: Fix crash with nr_cpus=1 option + +From: Helge Deller + +commit d3b3c637e4eb8d3bbe53e5692aee66add72f9851 upstream. + +John David Anglin reported that giving "nr_cpus=1" on the command +line causes a crash, while "maxcpus=1" works. + +Reported-by: John David Anglin +Signed-off-by: Helge Deller +Cc: stable@vger.kernel.org # v5.18+ +Signed-off-by: Greg Kroah-Hartman +--- + arch/parisc/kernel/smp.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/arch/parisc/kernel/smp.c ++++ b/arch/parisc/kernel/smp.c +@@ -440,7 +440,9 @@ int __cpu_up(unsigned int cpu, struct ta + if (cpu_online(cpu)) + return 0; + +- if (num_online_cpus() < setup_max_cpus && smp_boot_one_cpu(cpu, tidle)) ++ if (num_online_cpus() < nr_cpu_ids && ++ num_online_cpus() < setup_max_cpus && ++ smp_boot_one_cpu(cpu, tidle)) + return -EIO; + + return cpu_online(cpu) ? 0 : -EIO; diff --git a/queue-6.5/parisc-restore-__ldcw_align-for-pa-risc-2.0-processors.patch b/queue-6.5/parisc-restore-__ldcw_align-for-pa-risc-2.0-processors.patch new file mode 100644 index 00000000000..ac1482c7ded --- /dev/null +++ b/queue-6.5/parisc-restore-__ldcw_align-for-pa-risc-2.0-processors.patch @@ -0,0 +1,118 @@ +From 914988e099fc658436fbd7b8f240160c352b6552 Mon Sep 17 00:00:00 2001 +From: John David Anglin +Date: Tue, 19 Sep 2023 17:51:40 +0000 +Subject: parisc: Restore __ldcw_align for PA-RISC 2.0 processors + +From: John David Anglin + +commit 914988e099fc658436fbd7b8f240160c352b6552 upstream. + +Back in 2005, Kyle McMartin removed the 16-byte alignment for +ldcw semaphores on PA 2.0 machines (CONFIG_PA20). This broke +spinlocks on pre PA8800 processors. The main symptom was random +faults in mmap'd memory (e.g., gcc compilations, etc). + +Unfortunately, the errata for this ldcw change is lost. + +The issue is the 16-byte alignment required for ldcw semaphore +instructions can only be reduced to natural alignment when the +ldcw operation can be handled coherently in cache. Only PA8800 +and PA8900 processors actually support doing the operation in +cache. + +Aligning the spinlock dynamically adds two integer instructions +to each spinlock. + +Tested on rp3440, c8000 and a500. + +Signed-off-by: John David Anglin +Link: https://lore.kernel.org/linux-parisc/6b332788-2227-127f-ba6d-55e99ecf4ed8@bell.net/T/#t +Link: https://lore.kernel.org/linux-parisc/20050609050702.GB4641@roadwarrior.mcmartin.ca/ +Cc: stable@vger.kernel.org +Signed-off-by: Helge Deller +Signed-off-by: Greg Kroah-Hartman +--- + arch/parisc/include/asm/ldcw.h | 37 ++++++++++++++++--------------- + arch/parisc/include/asm/spinlock_types.h | 5 ---- + 2 files changed, 20 insertions(+), 22 deletions(-) + +--- a/arch/parisc/include/asm/ldcw.h ++++ b/arch/parisc/include/asm/ldcw.h +@@ -2,39 +2,42 @@ + #ifndef __PARISC_LDCW_H + #define __PARISC_LDCW_H + +-#ifndef CONFIG_PA20 + /* Because kmalloc only guarantees 8-byte alignment for kmalloc'd data, + and GCC only guarantees 8-byte alignment for stack locals, we can't + be assured of 16-byte alignment for atomic lock data even if we + specify "__attribute ((aligned(16)))" in the type declaration. So, + we use a struct containing an array of four ints for the atomic lock + type and dynamically select the 16-byte aligned int from the array +- for the semaphore. */ ++ for the semaphore. */ ++ ++/* From: "Jim Hull" ++ I've attached a summary of the change, but basically, for PA 2.0, as ++ long as the ",CO" (coherent operation) completer is implemented, then the ++ 16-byte alignment requirement for ldcw and ldcd is relaxed, and instead ++ they only require "natural" alignment (4-byte for ldcw, 8-byte for ++ ldcd). ++ ++ Although the cache control hint is accepted by all PA 2.0 processors, ++ it is only implemented on PA8800/PA8900 CPUs. Prior PA8X00 CPUs still ++ require 16-byte alignment. If the address is unaligned, the operation ++ of the instruction is undefined. The ldcw instruction does not generate ++ unaligned data reference traps so misaligned accesses are not detected. ++ This hid the problem for years. So, restore the 16-byte alignment dropped ++ by Kyle McMartin in "Remove __ldcw_align for PA-RISC 2.0 processors". */ + + #define __PA_LDCW_ALIGNMENT 16 +-#define __PA_LDCW_ALIGN_ORDER 4 + #define __ldcw_align(a) ({ \ + unsigned long __ret = (unsigned long) &(a)->lock[0]; \ + __ret = (__ret + __PA_LDCW_ALIGNMENT - 1) \ + & ~(__PA_LDCW_ALIGNMENT - 1); \ + (volatile unsigned int *) __ret; \ + }) +-#define __LDCW "ldcw" + +-#else /*CONFIG_PA20*/ +-/* From: "Jim Hull" +- I've attached a summary of the change, but basically, for PA 2.0, as +- long as the ",CO" (coherent operation) completer is specified, then the +- 16-byte alignment requirement for ldcw and ldcd is relaxed, and instead +- they only require "natural" alignment (4-byte for ldcw, 8-byte for +- ldcd). */ +- +-#define __PA_LDCW_ALIGNMENT 4 +-#define __PA_LDCW_ALIGN_ORDER 2 +-#define __ldcw_align(a) (&(a)->slock) ++#ifdef CONFIG_PA20 + #define __LDCW "ldcw,co" +- +-#endif /*!CONFIG_PA20*/ ++#else ++#define __LDCW "ldcw" ++#endif + + /* LDCW, the only atomic read-write operation PA-RISC has. *sigh*. + We don't explicitly expose that "*a" may be written as reload +--- a/arch/parisc/include/asm/spinlock_types.h ++++ b/arch/parisc/include/asm/spinlock_types.h +@@ -9,15 +9,10 @@ + #ifndef __ASSEMBLY__ + + typedef struct { +-#ifdef CONFIG_PA20 +- volatile unsigned int slock; +-# define __ARCH_SPIN_LOCK_UNLOCKED { __ARCH_SPIN_LOCK_UNLOCKED_VAL } +-#else + volatile unsigned int lock[4]; + # define __ARCH_SPIN_LOCK_UNLOCKED \ + { { __ARCH_SPIN_LOCK_UNLOCKED_VAL, __ARCH_SPIN_LOCK_UNLOCKED_VAL, \ + __ARCH_SPIN_LOCK_UNLOCKED_VAL, __ARCH_SPIN_LOCK_UNLOCKED_VAL } } +-#endif + } arch_spinlock_t; + + diff --git a/queue-6.5/rdma-bnxt_re-fix-the-handling-of-control-path-response-data.patch b/queue-6.5/rdma-bnxt_re-fix-the-handling-of-control-path-response-data.patch new file mode 100644 index 00000000000..1a26b67a0da --- /dev/null +++ b/queue-6.5/rdma-bnxt_re-fix-the-handling-of-control-path-response-data.patch @@ -0,0 +1,66 @@ +From 9fc5f9a92fe6897dbed7b9295b234cb7e3cc9d11 Mon Sep 17 00:00:00 2001 +From: Selvin Xavier +Date: Wed, 20 Sep 2023 01:41:19 -0700 +Subject: RDMA/bnxt_re: Fix the handling of control path response data + +From: Selvin Xavier + +commit 9fc5f9a92fe6897dbed7b9295b234cb7e3cc9d11 upstream. + +Flag that indicate control path command completion should be cleared +only after copying the command response data. As soon as the is_in_used +flag is clear, the waiting thread can proceed with wrong response +data. This wrong data is causing multiple issues like wrong lkey +used in data traffic and wrong AH Id etc. + +Use a memory barrier to ensure that the response data +is copied and visible to the process waiting on a different +cpu core before clearing the is_in_used flag. + +Clear the is_in_used after copying the command response. + +Fixes: bcfee4ce3e01 ("RDMA/bnxt_re: remove redundant cmdq_bitmap") +Signed-off-by: Saravanan Vajravel +Signed-off-by: Selvin Xavier +Link: https://lore.kernel.org/r/1695199280-13520-2-git-send-email-selvin.xavier@broadcom.com +Signed-off-by: Leon Romanovsky +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/hw/bnxt_re/qplib_rcfw.c | 11 +++++++++-- + 1 file changed, 9 insertions(+), 2 deletions(-) + +--- a/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c ++++ b/drivers/infiniband/hw/bnxt_re/qplib_rcfw.c +@@ -664,7 +664,6 @@ static int bnxt_qplib_process_qp_event(s + blocked = cookie & RCFW_CMD_IS_BLOCKING; + cookie &= RCFW_MAX_COOKIE_VALUE; + crsqe = &rcfw->crsqe_tbl[cookie]; +- crsqe->is_in_used = false; + + if (WARN_ONCE(test_bit(FIRMWARE_STALL_DETECTED, + &rcfw->cmdq.flags), +@@ -680,8 +679,14 @@ static int bnxt_qplib_process_qp_event(s + atomic_dec(&rcfw->timeout_send); + + if (crsqe->is_waiter_alive) { +- if (crsqe->resp) ++ if (crsqe->resp) { + memcpy(crsqe->resp, qp_event, sizeof(*qp_event)); ++ /* Insert write memory barrier to ensure that ++ * response data is copied before clearing the ++ * flags ++ */ ++ smp_wmb(); ++ } + if (!blocked) + wait_cmds++; + } +@@ -693,6 +698,8 @@ static int bnxt_qplib_process_qp_event(s + if (!is_waiter_alive) + crsqe->resp = NULL; + ++ crsqe->is_in_used = false; ++ + hwq->cons += req_size; + + /* This is a case to handle below scenario - diff --git a/queue-6.5/rdma-cma-fix-truncation-compilation-warning-in-make_cma_ports.patch b/queue-6.5/rdma-cma-fix-truncation-compilation-warning-in-make_cma_ports.patch new file mode 100644 index 00000000000..8dbef8b42fd --- /dev/null +++ b/queue-6.5/rdma-cma-fix-truncation-compilation-warning-in-make_cma_ports.patch @@ -0,0 +1,44 @@ +From 18126c767658ae8a831257c6cb7776c5ba5e7249 Mon Sep 17 00:00:00 2001 +From: Leon Romanovsky +Date: Mon, 11 Sep 2023 15:18:06 +0300 +Subject: RDMA/cma: Fix truncation compilation warning in make_cma_ports +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +From: Leon Romanovsky + +commit 18126c767658ae8a831257c6cb7776c5ba5e7249 upstream. + +The following compilation error is false alarm as RDMA devices don't +have such large amount of ports to actually cause to format truncation. + +drivers/infiniband/core/cma_configfs.c: In function ‘make_cma_ports’: +drivers/infiniband/core/cma_configfs.c:223:57: error: ‘snprintf’ output may be truncated before the last format character [-Werror=format-truncation=] + 223 | snprintf(port_str, sizeof(port_str), "%u", i + 1); + | ^ +drivers/infiniband/core/cma_configfs.c:223:17: note: ‘snprintf’ output between 2 and 11 bytes into a destination of size 10 + 223 | snprintf(port_str, sizeof(port_str), "%u", i + 1); + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +cc1: all warnings being treated as errors +make[5]: *** [scripts/Makefile.build:243: drivers/infiniband/core/cma_configfs.o] Error 1 + +Fixes: 045959db65c6 ("IB/cma: Add configfs for rdma_cm") +Link: https://lore.kernel.org/r/a7e3b347ee134167fa6a3787c56ef231a04bc8c2.1694434639.git.leonro@nvidia.com +Signed-off-by: Leon Romanovsky +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/core/cma_configfs.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/infiniband/core/cma_configfs.c ++++ b/drivers/infiniband/core/cma_configfs.c +@@ -217,7 +217,7 @@ static int make_cma_ports(struct cma_dev + return -ENOMEM; + + for (i = 0; i < ports_num; i++) { +- char port_str[10]; ++ char port_str[11]; + + ports[i].port_num = i + 1; + snprintf(port_str, sizeof(port_str), "%u", i + 1); diff --git a/queue-6.5/rdma-cma-initialize-ib_sa_multicast-structure-to-0-when-join.patch b/queue-6.5/rdma-cma-initialize-ib_sa_multicast-structure-to-0-when-join.patch new file mode 100644 index 00000000000..ef907a413ea --- /dev/null +++ b/queue-6.5/rdma-cma-initialize-ib_sa_multicast-structure-to-0-when-join.patch @@ -0,0 +1,38 @@ +From e0fe97efdb00f0f32b038a4836406a82886aec9c Mon Sep 17 00:00:00 2001 +From: Mark Zhang +Date: Wed, 27 Sep 2023 12:05:11 +0300 +Subject: RDMA/cma: Initialize ib_sa_multicast structure to 0 when join + +From: Mark Zhang + +commit e0fe97efdb00f0f32b038a4836406a82886aec9c upstream. + +Initialize the structure to 0 so that it's fields won't have random +values. For example fields like rec.traffic_class (as well as +rec.flow_label and rec.sl) is used to generate the user AH through: + cma_iboe_join_multicast + cma_make_mc_event + ib_init_ah_from_mcmember + +And a random traffic_class causes a random IP DSCP in RoCEv2. + +Fixes: b5de0c60cc30 ("RDMA/cma: Fix use after free race in roce multicast join") +Signed-off-by: Mark Zhang +Link: https://lore.kernel.org/r/20230927090511.603595-1-markzhang@nvidia.com +Signed-off-by: Leon Romanovsky +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/core/cma.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/infiniband/core/cma.c ++++ b/drivers/infiniband/core/cma.c +@@ -4946,7 +4946,7 @@ static int cma_iboe_join_multicast(struc + int err = 0; + struct sockaddr *addr = (struct sockaddr *)&mc->addr; + struct net_device *ndev = NULL; +- struct ib_sa_multicast ib; ++ struct ib_sa_multicast ib = {}; + enum ib_gid_type gid_type; + bool send_only; + diff --git a/queue-6.5/rdma-core-require-admin-capabilities-to-set-system-parameters.patch b/queue-6.5/rdma-core-require-admin-capabilities-to-set-system-parameters.patch new file mode 100644 index 00000000000..4506f7ff379 --- /dev/null +++ b/queue-6.5/rdma-core-require-admin-capabilities-to-set-system-parameters.patch @@ -0,0 +1,31 @@ +From c38d23a54445f9a8aa6831fafc9af0496ba02f9e Mon Sep 17 00:00:00 2001 +From: Leon Romanovsky +Date: Wed, 4 Oct 2023 21:17:49 +0300 +Subject: RDMA/core: Require admin capabilities to set system parameters + +From: Leon Romanovsky + +commit c38d23a54445f9a8aa6831fafc9af0496ba02f9e upstream. + +Like any other set command, require admin permissions to do it. + +Cc: stable@vger.kernel.org +Fixes: 2b34c5580226 ("RDMA/core: Add command to set ib_core device net namspace sharing mode") +Link: https://lore.kernel.org/r/75d329fdd7381b52cbdf87910bef16c9965abb1f.1696443438.git.leon@kernel.org +Reviewed-by: Parav Pandit +Signed-off-by: Leon Romanovsky +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/core/nldev.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/infiniband/core/nldev.c ++++ b/drivers/infiniband/core/nldev.c +@@ -2529,6 +2529,7 @@ static const struct rdma_nl_cbs nldev_cb + }, + [RDMA_NLDEV_CMD_SYS_SET] = { + .doit = nldev_set_sys_set_doit, ++ .flags = RDMA_NL_ADMIN_PERM, + }, + [RDMA_NLDEV_CMD_STAT_SET] = { + .doit = nldev_stat_set_doit, diff --git a/queue-6.5/rdma-mlx5-fix-assigning-access-flags-to-cache-mkeys.patch b/queue-6.5/rdma-mlx5-fix-assigning-access-flags-to-cache-mkeys.patch new file mode 100644 index 00000000000..e3afbc49f45 --- /dev/null +++ b/queue-6.5/rdma-mlx5-fix-assigning-access-flags-to-cache-mkeys.patch @@ -0,0 +1,46 @@ +From 4f14c6c0213e1def48f0f887d35f44095416c67d Mon Sep 17 00:00:00 2001 +From: Michael Guralnik +Date: Wed, 20 Sep 2023 13:01:54 +0300 +Subject: RDMA/mlx5: Fix assigning access flags to cache mkeys + +From: Michael Guralnik + +commit 4f14c6c0213e1def48f0f887d35f44095416c67d upstream. + +After the change to use dynamic cache structure, new cache entries +can be added and the mkey allocation can no longer assume that all +mkeys created for the cache have access_flags equal to zero. + +Example of a flow that exposes the issue: +A user registers MR with RO on a HCA that cannot UMR RO and the mkey is +created outside of the cache. When the user deregisters the MR, a new +cache entry is created to store mkeys with RO. + +Later, the user registers 2 MRs with RO. The first MR is reused from the +new cache entry. When we try to get the second mkey from the cache we see +the entry is empty so we go to the MR cache mkey allocation flow which +would have allocated a mkey with no access flags, resulting the user getting +a MR without RO. + +Fixes: dd1b913fb0d0 ("RDMA/mlx5: Cache all user cacheable mkeys on dereg MR flow") +Reviewed-by: Edward Srouji +Signed-off-by: Michael Guralnik +Link: https://lore.kernel.org/r/8a802700b82def3ace3f77cd7a9ad9d734af87e7.1695203958.git.leonro@nvidia.com +Signed-off-by: Leon Romanovsky +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/hw/mlx5/mr.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/drivers/infiniband/hw/mlx5/mr.c ++++ b/drivers/infiniband/hw/mlx5/mr.c +@@ -301,7 +301,8 @@ static int get_mkc_octo_size(unsigned in + + static void set_cache_mkc(struct mlx5_cache_ent *ent, void *mkc) + { +- set_mkc_access_pd_addr_fields(mkc, 0, 0, ent->dev->umrc.pd); ++ set_mkc_access_pd_addr_fields(mkc, ent->rb_key.access_flags, 0, ++ ent->dev->umrc.pd); + MLX5_SET(mkc, mkc, free, 1); + MLX5_SET(mkc, mkc, umr_en, 1); + MLX5_SET(mkc, mkc, access_mode_1_0, ent->rb_key.access_mode & 0x3); diff --git a/queue-6.5/rdma-mlx5-fix-mkey-cache-possible-deadlock-on-cleanup.patch b/queue-6.5/rdma-mlx5-fix-mkey-cache-possible-deadlock-on-cleanup.patch new file mode 100644 index 00000000000..13409bb0c0e --- /dev/null +++ b/queue-6.5/rdma-mlx5-fix-mkey-cache-possible-deadlock-on-cleanup.patch @@ -0,0 +1,151 @@ +From 374012b0045780b7ad498be62e85153009bb7fe9 Mon Sep 17 00:00:00 2001 +From: Shay Drory +Date: Tue, 12 Sep 2023 13:07:45 +0300 +Subject: RDMA/mlx5: Fix mkey cache possible deadlock on cleanup + +From: Shay Drory + +commit 374012b0045780b7ad498be62e85153009bb7fe9 upstream. + +Fix the deadlock by refactoring the MR cache cleanup flow to flush the +workqueue without holding the rb_lock. +This adds a race between cache cleanup and creation of new entries which +we solve by denied creation of new entries after cache cleanup started. + +Lockdep: +WARNING: possible circular locking dependency detected + [ 2785.326074 ] 6.2.0-rc6_for_upstream_debug_2023_01_31_14_02 #1 Not tainted + [ 2785.339778 ] ------------------------------------------------------ + [ 2785.340848 ] devlink/53872 is trying to acquire lock: + [ 2785.341701 ] ffff888124f8c0c8 ((work_completion)(&(&ent->dwork)->work)){+.+.}-{0:0}, at: __flush_work+0xc8/0x900 + [ 2785.343403 ] + [ 2785.343403 ] but task is already holding lock: + [ 2785.344464 ] ffff88817e8f1260 (&dev->cache.rb_lock){+.+.}-{3:3}, at: mlx5_mkey_cache_cleanup+0x77/0x250 [mlx5_ib] + [ 2785.346273 ] + [ 2785.346273 ] which lock already depends on the new lock. + [ 2785.346273 ] + [ 2785.347720 ] + [ 2785.347720 ] the existing dependency chain (in reverse order) is: + [ 2785.349003 ] + [ 2785.349003 ] -> #1 (&dev->cache.rb_lock){+.+.}-{3:3}: + [ 2785.350160 ] __mutex_lock+0x14c/0x15c0 + [ 2785.350962 ] delayed_cache_work_func+0x2d1/0x610 [mlx5_ib] + [ 2785.352044 ] process_one_work+0x7c2/0x1310 + [ 2785.352879 ] worker_thread+0x59d/0xec0 + [ 2785.353636 ] kthread+0x28f/0x330 + [ 2785.354370 ] ret_from_fork+0x1f/0x30 + [ 2785.355135 ] + [ 2785.355135 ] -> #0 ((work_completion)(&(&ent->dwork)->work)){+.+.}-{0:0}: + [ 2785.356515 ] __lock_acquire+0x2d8a/0x5fe0 + [ 2785.357349 ] lock_acquire+0x1c1/0x540 + [ 2785.358121 ] __flush_work+0xe8/0x900 + [ 2785.358852 ] __cancel_work_timer+0x2c7/0x3f0 + [ 2785.359711 ] mlx5_mkey_cache_cleanup+0xfb/0x250 [mlx5_ib] + [ 2785.360781 ] mlx5_ib_stage_pre_ib_reg_umr_cleanup+0x16/0x30 [mlx5_ib] + [ 2785.361969 ] __mlx5_ib_remove+0x68/0x120 [mlx5_ib] + [ 2785.362960 ] mlx5r_remove+0x63/0x80 [mlx5_ib] + [ 2785.363870 ] auxiliary_bus_remove+0x52/0x70 + [ 2785.364715 ] device_release_driver_internal+0x3c1/0x600 + [ 2785.365695 ] bus_remove_device+0x2a5/0x560 + [ 2785.366525 ] device_del+0x492/0xb80 + [ 2785.367276 ] mlx5_detach_device+0x1a9/0x360 [mlx5_core] + [ 2785.368615 ] mlx5_unload_one_devl_locked+0x5a/0x110 [mlx5_core] + [ 2785.369934 ] mlx5_devlink_reload_down+0x292/0x580 [mlx5_core] + [ 2785.371292 ] devlink_reload+0x439/0x590 + [ 2785.372075 ] devlink_nl_cmd_reload+0xaef/0xff0 + [ 2785.372973 ] genl_family_rcv_msg_doit.isra.0+0x1bd/0x290 + [ 2785.374011 ] genl_rcv_msg+0x3ca/0x6c0 + [ 2785.374798 ] netlink_rcv_skb+0x12c/0x360 + [ 2785.375612 ] genl_rcv+0x24/0x40 + [ 2785.376295 ] netlink_unicast+0x438/0x710 + [ 2785.377121 ] netlink_sendmsg+0x7a1/0xca0 + [ 2785.377926 ] sock_sendmsg+0xc5/0x190 + [ 2785.378668 ] __sys_sendto+0x1bc/0x290 + [ 2785.379440 ] __x64_sys_sendto+0xdc/0x1b0 + [ 2785.380255 ] do_syscall_64+0x3d/0x90 + [ 2785.381031 ] entry_SYSCALL_64_after_hwframe+0x46/0xb0 + [ 2785.381967 ] + [ 2785.381967 ] other info that might help us debug this: + [ 2785.381967 ] + [ 2785.383448 ] Possible unsafe locking scenario: + [ 2785.383448 ] + [ 2785.384544 ] CPU0 CPU1 + [ 2785.385383 ] ---- ---- + [ 2785.386193 ] lock(&dev->cache.rb_lock); + [ 2785.386940 ] lock((work_completion)(&(&ent->dwork)->work)); + [ 2785.388327 ] lock(&dev->cache.rb_lock); + [ 2785.389425 ] lock((work_completion)(&(&ent->dwork)->work)); + [ 2785.390414 ] + [ 2785.390414 ] *** DEADLOCK *** + [ 2785.390414 ] + [ 2785.391579 ] 6 locks held by devlink/53872: + [ 2785.392341 ] #0: ffffffff84c17a50 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40 + [ 2785.393630 ] #1: ffff888142280218 (&devlink->lock_key){+.+.}-{3:3}, at: devlink_get_from_attrs_lock+0x12d/0x2d0 + [ 2785.395324 ] #2: ffff8881422d3c38 (&dev->lock_key){+.+.}-{3:3}, at: mlx5_unload_one_devl_locked+0x4a/0x110 [mlx5_core] + [ 2785.397322 ] #3: ffffffffa0e59068 (mlx5_intf_mutex){+.+.}-{3:3}, at: mlx5_detach_device+0x60/0x360 [mlx5_core] + [ 2785.399231 ] #4: ffff88810e3cb0e8 (&dev->mutex){....}-{3:3}, at: device_release_driver_internal+0x8d/0x600 + [ 2785.400864 ] #5: ffff88817e8f1260 (&dev->cache.rb_lock){+.+.}-{3:3}, at: mlx5_mkey_cache_cleanup+0x77/0x250 [mlx5_ib] + +Fixes: b95845178328 ("RDMA/mlx5: Change the cache structure to an RB-tree") +Signed-off-by: Shay Drory +Signed-off-by: Michael Guralnik +Signed-off-by: Leon Romanovsky +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/hw/mlx5/mlx5_ib.h | 1 + + drivers/infiniband/hw/mlx5/mr.c | 16 ++++++++++++++-- + 2 files changed, 15 insertions(+), 2 deletions(-) + +--- a/drivers/infiniband/hw/mlx5/mlx5_ib.h ++++ b/drivers/infiniband/hw/mlx5/mlx5_ib.h +@@ -797,6 +797,7 @@ struct mlx5_mkey_cache { + struct dentry *fs_root; + unsigned long last_add; + struct delayed_work remove_ent_dwork; ++ u8 disable: 1; + }; + + struct mlx5_ib_port_resources { +--- a/drivers/infiniband/hw/mlx5/mr.c ++++ b/drivers/infiniband/hw/mlx5/mr.c +@@ -1024,19 +1024,27 @@ void mlx5_mkey_cache_cleanup(struct mlx5 + if (!dev->cache.wq) + return; + +- cancel_delayed_work_sync(&dev->cache.remove_ent_dwork); + mutex_lock(&dev->cache.rb_lock); ++ dev->cache.disable = true; + for (node = rb_first(root); node; node = rb_next(node)) { + ent = rb_entry(node, struct mlx5_cache_ent, node); + xa_lock_irq(&ent->mkeys); + ent->disabled = true; + xa_unlock_irq(&ent->mkeys); +- cancel_delayed_work_sync(&ent->dwork); + } ++ mutex_unlock(&dev->cache.rb_lock); ++ ++ /* ++ * After all entries are disabled and will not reschedule on WQ, ++ * flush it and all async commands. ++ */ ++ flush_workqueue(dev->cache.wq); + + mlx5_mkey_cache_debugfs_cleanup(dev); + mlx5_cmd_cleanup_async_ctx(&dev->async_ctx); + ++ /* At this point all entries are disabled and have no concurrent work. */ ++ mutex_lock(&dev->cache.rb_lock); + node = rb_first(root); + while (node) { + ent = rb_entry(node, struct mlx5_cache_ent, node); +@@ -1815,6 +1823,10 @@ static int cache_ent_find_and_store(stru + } + + mutex_lock(&cache->rb_lock); ++ if (cache->disable) { ++ mutex_unlock(&cache->rb_lock); ++ return 0; ++ } + ent = mkey_cache_ent_from_rb_key(dev, mr->mmkey.rb_key); + if (ent) { + if (ent->rb_key.ndescs == mr->mmkey.rb_key.ndescs) { diff --git a/queue-6.5/rdma-mlx5-fix-mutex-unlocking-on-error-flow-for-steering-anchor-creation.patch b/queue-6.5/rdma-mlx5-fix-mutex-unlocking-on-error-flow-for-steering-anchor-creation.patch new file mode 100644 index 00000000000..2a8d9f64f60 --- /dev/null +++ b/queue-6.5/rdma-mlx5-fix-mutex-unlocking-on-error-flow-for-steering-anchor-creation.patch @@ -0,0 +1,34 @@ +From 2fad8f06a582cd431d398a0b3f9be21d069603ab Mon Sep 17 00:00:00 2001 +From: Hamdan Igbaria +Date: Wed, 20 Sep 2023 13:01:55 +0300 +Subject: RDMA/mlx5: Fix mutex unlocking on error flow for steering anchor creation + +From: Hamdan Igbaria + +commit 2fad8f06a582cd431d398a0b3f9be21d069603ab upstream. + +The mutex was not unlocked on some of the error flows. +Moved the unlock location to include all the error flow scenarios. + +Fixes: e1f4a52ac171 ("RDMA/mlx5: Create an indirect flow table for steering anchor") +Reviewed-by: Mark Bloch +Signed-off-by: Hamdan Igbaria +Link: https://lore.kernel.org/r/1244a69d783da997c0af0b827c622eb00495492e.1695203958.git.leonro@nvidia.com +Signed-off-by: Leon Romanovsky +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/hw/mlx5/fs.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/infiniband/hw/mlx5/fs.c ++++ b/drivers/infiniband/hw/mlx5/fs.c +@@ -2470,8 +2470,8 @@ destroy_res: + mlx5_steering_anchor_destroy_res(ft_prio); + put_flow_table: + put_flow_table(dev, ft_prio, true); +- mutex_unlock(&dev->flow_db->lock); + free_obj: ++ mutex_unlock(&dev->flow_db->lock); + kfree(obj); + + return err; diff --git a/queue-6.5/rdma-mlx5-fix-null-string-error.patch b/queue-6.5/rdma-mlx5-fix-null-string-error.patch new file mode 100644 index 00000000000..56a6bc310d3 --- /dev/null +++ b/queue-6.5/rdma-mlx5-fix-null-string-error.patch @@ -0,0 +1,31 @@ +From dab994bcc609a172bfdab15a0d4cb7e50e8b5458 Mon Sep 17 00:00:00 2001 +From: Shay Drory +Date: Wed, 20 Sep 2023 13:01:56 +0300 +Subject: RDMA/mlx5: Fix NULL string error + +From: Shay Drory + +commit dab994bcc609a172bfdab15a0d4cb7e50e8b5458 upstream. + +checkpath is complaining about NULL string, change it to 'Unknown'. + +Fixes: 37aa5c36aa70 ("IB/mlx5: Add UARs write-combining and non-cached mapping") +Signed-off-by: Shay Drory +Link: https://lore.kernel.org/r/8638e5c14fadbde5fa9961874feae917073af920.1695203958.git.leonro@nvidia.com +Signed-off-by: Leon Romanovsky +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/hw/mlx5/main.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/infiniband/hw/mlx5/main.c ++++ b/drivers/infiniband/hw/mlx5/main.c +@@ -2070,7 +2070,7 @@ static inline char *mmap_cmd2str(enum ml + case MLX5_IB_MMAP_DEVICE_MEM: + return "Device Memory"; + default: +- return NULL; ++ return "Unknown"; + } + } + diff --git a/queue-6.5/rdma-siw-fix-connection-failure-handling.patch b/queue-6.5/rdma-siw-fix-connection-failure-handling.patch new file mode 100644 index 00000000000..bad20b800a3 --- /dev/null +++ b/queue-6.5/rdma-siw-fix-connection-failure-handling.patch @@ -0,0 +1,71 @@ +From 53a3f777049771496f791504e7dc8ef017cba590 Mon Sep 17 00:00:00 2001 +From: Bernard Metzler +Date: Tue, 5 Sep 2023 16:58:22 +0200 +Subject: RDMA/siw: Fix connection failure handling + +From: Bernard Metzler + +commit 53a3f777049771496f791504e7dc8ef017cba590 upstream. + +In case immediate MPA request processing fails, the newly +created endpoint unlinks the listening endpoint and is +ready to be dropped. This special case was not handled +correctly by the code handling the later TCP socket close, +causing a NULL dereference crash in siw_cm_work_handler() +when dereferencing a NULL listener. We now also cancel +the useless MPA timeout, if immediate MPA request +processing fails. + +This patch furthermore simplifies MPA processing in general: +Scheduling a useless TCP socket read in sk_data_ready() upcall +is now surpressed, if the socket is already moved out of +TCP_ESTABLISHED state. + +Fixes: 6c52fdc244b5 ("rdma/siw: connection management") +Signed-off-by: Bernard Metzler +Link: https://lore.kernel.org/r/20230905145822.446263-1-bmt@zurich.ibm.com +Signed-off-by: Leon Romanovsky +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/sw/siw/siw_cm.c | 16 ++++++++++++---- + 1 file changed, 12 insertions(+), 4 deletions(-) + +--- a/drivers/infiniband/sw/siw/siw_cm.c ++++ b/drivers/infiniband/sw/siw/siw_cm.c +@@ -976,6 +976,7 @@ static void siw_accept_newconn(struct si + siw_cep_put(cep); + new_cep->listen_cep = NULL; + if (rv) { ++ siw_cancel_mpatimer(new_cep); + siw_cep_set_free(new_cep); + goto error; + } +@@ -1100,9 +1101,12 @@ static void siw_cm_work_handler(struct w + /* + * Socket close before MPA request received. + */ +- siw_dbg_cep(cep, "no mpareq: drop listener\n"); +- siw_cep_put(cep->listen_cep); +- cep->listen_cep = NULL; ++ if (cep->listen_cep) { ++ siw_dbg_cep(cep, ++ "no mpareq: drop listener\n"); ++ siw_cep_put(cep->listen_cep); ++ cep->listen_cep = NULL; ++ } + } + } + release_cep = 1; +@@ -1227,7 +1231,11 @@ static void siw_cm_llp_data_ready(struct + if (!cep) + goto out; + +- siw_dbg_cep(cep, "state: %d\n", cep->state); ++ siw_dbg_cep(cep, "cep state: %d, socket state %d\n", ++ cep->state, sk->sk_state); ++ ++ if (sk->sk_state != TCP_ESTABLISHED) ++ goto out; + + switch (cep->state) { + case SIW_EPSTATE_RDMA_MODE: diff --git a/queue-6.5/rdma-srp-do-not-call-scsi_done-from-srp_abort.patch b/queue-6.5/rdma-srp-do-not-call-scsi_done-from-srp_abort.patch new file mode 100644 index 00000000000..7c6dd4444aa --- /dev/null +++ b/queue-6.5/rdma-srp-do-not-call-scsi_done-from-srp_abort.patch @@ -0,0 +1,66 @@ +From e193b7955dfad68035b983a0011f4ef3590c85eb Mon Sep 17 00:00:00 2001 +From: Bart Van Assche +Date: Wed, 23 Aug 2023 13:57:27 -0700 +Subject: RDMA/srp: Do not call scsi_done() from srp_abort() + +From: Bart Van Assche + +commit e193b7955dfad68035b983a0011f4ef3590c85eb upstream. + +After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler +callback, it performs one of the following actions: +* Call scsi_queue_insert(). +* Call scsi_finish_command(). +* Call scsi_eh_scmd_add(). +Hence, SCSI abort handlers must not call scsi_done(). Otherwise all +the above actions would trigger a use-after-free. Hence remove the +scsi_done() call from srp_abort(). Keep the srp_free_req() call +before returning SUCCESS because we may not see the command again if +SUCCESS is returned. + +Cc: Bob Pearson +Cc: Shinichiro Kawasaki +Fixes: d8536670916a ("IB/srp: Avoid having aborted requests hang") +Signed-off-by: Bart Van Assche +Link: https://lore.kernel.org/r/20230823205727.505681-1-bvanassche@acm.org +Signed-off-by: Leon Romanovsky +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/ulp/srp/ib_srp.c | 16 +++++----------- + 1 file changed, 5 insertions(+), 11 deletions(-) + +--- a/drivers/infiniband/ulp/srp/ib_srp.c ++++ b/drivers/infiniband/ulp/srp/ib_srp.c +@@ -2784,7 +2784,6 @@ static int srp_abort(struct scsi_cmnd *s + u32 tag; + u16 ch_idx; + struct srp_rdma_ch *ch; +- int ret; + + shost_printk(KERN_ERR, target->scsi_host, "SRP abort called\n"); + +@@ -2798,19 +2797,14 @@ static int srp_abort(struct scsi_cmnd *s + shost_printk(KERN_ERR, target->scsi_host, + "Sending SRP abort for tag %#x\n", tag); + if (srp_send_tsk_mgmt(ch, tag, scmnd->device->lun, +- SRP_TSK_ABORT_TASK, NULL) == 0) +- ret = SUCCESS; +- else if (target->rport->state == SRP_RPORT_LOST) +- ret = FAST_IO_FAIL; +- else +- ret = FAILED; +- if (ret == SUCCESS) { ++ SRP_TSK_ABORT_TASK, NULL) == 0) { + srp_free_req(ch, req, scmnd, 0); +- scmnd->result = DID_ABORT << 16; +- scsi_done(scmnd); ++ return SUCCESS; + } ++ if (target->rport->state == SRP_RPORT_LOST) ++ return FAST_IO_FAIL; + +- return ret; ++ return FAILED; + } + + static int srp_reset_device(struct scsi_cmnd *scmnd) diff --git a/queue-6.5/rdma-uverbs-fix-typo-of-sizeof-argument.patch b/queue-6.5/rdma-uverbs-fix-typo-of-sizeof-argument.patch new file mode 100644 index 00000000000..bf4139981a8 --- /dev/null +++ b/queue-6.5/rdma-uverbs-fix-typo-of-sizeof-argument.patch @@ -0,0 +1,35 @@ +From c489800e0d48097fc6afebd862c6afa039110a36 Mon Sep 17 00:00:00 2001 +From: Konstantin Meskhidze +Date: Tue, 5 Sep 2023 18:32:58 +0800 +Subject: RDMA/uverbs: Fix typo of sizeof argument + +From: Konstantin Meskhidze + +commit c489800e0d48097fc6afebd862c6afa039110a36 upstream. + +Since size of 'hdr' pointer and '*hdr' structure is equal on 64-bit +machines issue probably didn't cause any wrong behavior. But anyway, +fixing of typo is required. + +Fixes: da0f60df7bd5 ("RDMA/uverbs: Prohibit write() calls with too small buffers") +Co-developed-by: Ivanov Mikhail +Signed-off-by: Ivanov Mikhail +Signed-off-by: Konstantin Meskhidze +Link: https://lore.kernel.org/r/20230905103258.1738246-1-konstantin.meskhidze@huawei.com +Signed-off-by: Leon Romanovsky +Signed-off-by: Greg Kroah-Hartman +--- + drivers/infiniband/core/uverbs_main.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/infiniband/core/uverbs_main.c ++++ b/drivers/infiniband/core/uverbs_main.c +@@ -535,7 +535,7 @@ static ssize_t verify_hdr(struct ib_uver + if (hdr->in_words * 4 != count) + return -EINVAL; + +- if (count < method_elm->req_size + sizeof(hdr)) { ++ if (count < method_elm->req_size + sizeof(*hdr)) { + /* + * rdma-core v18 and v19 have a bug where they send DESTROY_CQ + * with a 16 byte write instead of 24. Old kernels didn't diff --git a/queue-6.5/series b/queue-6.5/series index eb1ee4350e1..ac67013ab85 100644 --- a/queue-6.5/series +++ b/queue-6.5/series @@ -134,3 +134,22 @@ hid-nvidia-shield-fix-a-missing-led_classdev_unregis.patch hid-sony-remove-duplicate-null-check-before-calling-.patch hid-intel-ish-hid-ipc-disable-and-reenable-acpi-gpe-.patch net-lan743x-also-select-phylib.patch +parisc-restore-__ldcw_align-for-pa-risc-2.0-processors.patch +smb-use-kernel_connect-and-kernel_bind.patch +parisc-fix-crash-with-nr_cpus-1-option.patch +dm-zoned-free-dmz-ddev-array-in-dmz_put_zoned_devices.patch +rdma-core-require-admin-capabilities-to-set-system-parameters.patch +of-dynamic-fix-potential-memory-leak-in-of_changeset_action.patch +ib-mlx4-fix-the-size-of-a-buffer-in-add_port_entries.patch +gpio-aspeed-fix-the-gpio-number-passed-to-pinctrl_gpio_set_config.patch +gpio-pxa-disable-pinctrl-calls-for-mmp_gpio.patch +rdma-cma-initialize-ib_sa_multicast-structure-to-0-when-join.patch +rdma-cma-fix-truncation-compilation-warning-in-make_cma_ports.patch +rdma-bnxt_re-fix-the-handling-of-control-path-response-data.patch +rdma-uverbs-fix-typo-of-sizeof-argument.patch +rdma-srp-do-not-call-scsi_done-from-srp_abort.patch +rdma-siw-fix-connection-failure-handling.patch +rdma-mlx5-fix-mkey-cache-possible-deadlock-on-cleanup.patch +rdma-mlx5-fix-assigning-access-flags-to-cache-mkeys.patch +rdma-mlx5-fix-mutex-unlocking-on-error-flow-for-steering-anchor-creation.patch +rdma-mlx5-fix-null-string-error.patch diff --git a/queue-6.5/smb-use-kernel_connect-and-kernel_bind.patch b/queue-6.5/smb-use-kernel_connect-and-kernel_bind.patch new file mode 100644 index 00000000000..75bdde5bd84 --- /dev/null +++ b/queue-6.5/smb-use-kernel_connect-and-kernel_bind.patch @@ -0,0 +1,51 @@ +From cedc019b9f260facfadd20c6c490e403abf292e3 Mon Sep 17 00:00:00 2001 +From: Jordan Rife +Date: Tue, 3 Oct 2023 20:13:03 -0500 +Subject: smb: use kernel_connect() and kernel_bind() + +From: Jordan Rife + +commit cedc019b9f260facfadd20c6c490e403abf292e3 upstream. + +Recent changes to kernel_connect() and kernel_bind() ensure that +callers are insulated from changes to the address parameter made by BPF +SOCK_ADDR hooks. This patch wraps direct calls to ops->connect() and +ops->bind() with kernel_connect() and kernel_bind() to ensure that SMB +mounts do not see their mount address overwritten in such cases. + +Link: https://lore.kernel.org/netdev/9944248dba1bce861375fcce9de663934d933ba9.camel@redhat.com/ +Cc: # 6.0+ +Signed-off-by: Jordan Rife +Acked-by: Paulo Alcantara (SUSE) +Signed-off-by: Steve French +Signed-off-by: Greg Kroah-Hartman +--- + fs/smb/client/connect.c | 10 +++++----- + 1 file changed, 5 insertions(+), 5 deletions(-) + +--- a/fs/smb/client/connect.c ++++ b/fs/smb/client/connect.c +@@ -2890,9 +2890,9 @@ bind_socket(struct TCP_Server_Info *serv + if (server->srcaddr.ss_family != AF_UNSPEC) { + /* Bind to the specified local IP address */ + struct socket *socket = server->ssocket; +- rc = socket->ops->bind(socket, +- (struct sockaddr *) &server->srcaddr, +- sizeof(server->srcaddr)); ++ rc = kernel_bind(socket, ++ (struct sockaddr *) &server->srcaddr, ++ sizeof(server->srcaddr)); + if (rc < 0) { + struct sockaddr_in *saddr4; + struct sockaddr_in6 *saddr6; +@@ -3041,8 +3041,8 @@ generic_ip_connect(struct TCP_Server_Inf + socket->sk->sk_sndbuf, + socket->sk->sk_rcvbuf, socket->sk->sk_rcvtimeo); + +- rc = socket->ops->connect(socket, saddr, slen, +- server->noblockcnt ? O_NONBLOCK : 0); ++ rc = kernel_connect(socket, saddr, slen, ++ server->noblockcnt ? O_NONBLOCK : 0); + /* + * When mounting SMB root file systems, we do not want to block in + * connect. Otherwise bail out and then let cifs_reconnect() perform