--- /dev/null
+From 4ee5d556c5c15eaa7c18c3f7725bd4e2eff8edf5 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 7 Aug 2024 10:47:25 +0100
+Subject: 9p: Avoid creating multiple slab caches with the same name
+
+From: Pedro Falcato <pedro.falcato@gmail.com>
+
+[ Upstream commit 79efebae4afc2221fa814c3cae001bede66ab259 ]
+
+In the spirit of [1], avoid creating multiple slab caches with the same
+name. Instead, add the dev_name into the mix.
+
+[1]: https://lore.kernel.org/all/20240807090746.2146479-1-pedro.falcato@gmail.com/
+
+Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
+Reported-by: syzbot+3c5d43e97993e1fa612b@syzkaller.appspotmail.com
+Message-ID: <20240807094725.2193423-1-pedro.falcato@gmail.com>
+Signed-off-by: Dominique Martinet <asmadeus@codewreck.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ net/9p/client.c | 10 +++++++++-
+ 1 file changed, 9 insertions(+), 1 deletion(-)
+
+diff --git a/net/9p/client.c b/net/9p/client.c
+index 0fc2d706d9c23..18db0e23e2f15 100644
+--- a/net/9p/client.c
++++ b/net/9p/client.c
+@@ -969,6 +969,7 @@ struct p9_client *p9_client_create(const char *dev_name, char *options)
+ int err;
+ struct p9_client *clnt;
+ char *client_id;
++ char *cache_name;
+
+ err = 0;
+ clnt = kmalloc(sizeof(*clnt), GFP_KERNEL);
+@@ -1026,15 +1027,22 @@ struct p9_client *p9_client_create(const char *dev_name, char *options)
+ if (err)
+ goto close_trans;
+
++ cache_name = kasprintf(GFP_KERNEL, "9p-fcall-cache-%s", dev_name);
++ if (!cache_name) {
++ err = -ENOMEM;
++ goto close_trans;
++ }
++
+ /* P9_HDRSZ + 4 is the smallest packet header we can have that is
+ * followed by data accessed from userspace by read
+ */
+ clnt->fcall_cache =
+- kmem_cache_create_usercopy("9p-fcall-cache", clnt->msize,
++ kmem_cache_create_usercopy(cache_name, clnt->msize,
+ 0, 0, P9_HDRSZ + 4,
+ clnt->msize - (P9_HDRSZ + 4),
+ NULL);
+
++ kfree(cache_name);
+ return clnt;
+
+ close_trans:
+--
+2.43.0
+
--- /dev/null
+From 08742f8e7e81b6b6bdfb5a94d9dcd5413cc4901f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 7 Oct 2024 16:44:16 +0530
+Subject: block: Fix elevator_get_default() checking for NULL q->tag_set
+
+From: SurajSonawane2415 <surajsonawane0215@gmail.com>
+
+[ Upstream commit b402328a24ee7193a8ab84277c0c90ae16768126 ]
+
+elevator_get_default() and elv_support_iosched() both check for whether
+or not q->tag_set is non-NULL, however it's not possible for them to be
+NULL. This messes up some static checkers, as the checking of tag_set
+isn't consistent.
+
+Remove the checks, which both simplifies the logic and avoids checker
+errors.
+
+Signed-off-by: SurajSonawane2415 <surajsonawane0215@gmail.com>
+Link: https://lore.kernel.org/r/20241007111416.13814-1-surajsonawane0215@gmail.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ block/elevator.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/block/elevator.c b/block/elevator.c
+index bd71f0fc4e4b6..06288117e2dd6 100644
+--- a/block/elevator.c
++++ b/block/elevator.c
+@@ -624,7 +624,7 @@ static int elevator_switch_mq(struct request_queue *q,
+ static inline bool elv_support_iosched(struct request_queue *q)
+ {
+ if (!queue_is_mq(q) ||
+- (q->tag_set && (q->tag_set->flags & BLK_MQ_F_NO_SCHED)))
++ (q->tag_set->flags & BLK_MQ_F_NO_SCHED))
+ return false;
+ return true;
+ }
+@@ -635,7 +635,7 @@ static inline bool elv_support_iosched(struct request_queue *q)
+ */
+ static struct elevator_type *elevator_get_default(struct request_queue *q)
+ {
+- if (q->tag_set && q->tag_set->flags & BLK_MQ_F_NO_SCHED_BY_DEFAULT)
++ if (q->tag_set->flags & BLK_MQ_F_NO_SCHED_BY_DEFAULT)
+ return NULL;
+
+ if (q->nr_hw_queues != 1 &&
+--
+2.43.0
+
--- /dev/null
+From b2d1f1113e2fc90c0523e6a5aff97557f83f050a Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 8 Oct 2024 17:07:35 -0400
+Subject: bpf: use kvzmalloc to allocate BPF verifier environment
+
+From: Rik van Riel <riel@surriel.com>
+
+[ Upstream commit 434247637c66e1be2bc71a9987d4c3f0d8672387 ]
+
+The kzmalloc call in bpf_check can fail when memory is very fragmented,
+which in turn can lead to an OOM kill.
+
+Use kvzmalloc to fall back to vmalloc when memory is too fragmented to
+allocate an order 3 sized bpf verifier environment.
+
+Admittedly this is not a very common case, and only happens on systems
+where memory has already been squeezed close to the limit, but this does
+not seem like much of a hot path, and it's a simple enough fix.
+
+Signed-off-by: Rik van Riel <riel@surriel.com>
+Reviewed-by: Shakeel Butt <shakeel.butt@linux.dev>
+Link: https://lore.kernel.org/r/20241008170735.16766766@imladris.surriel.com
+Signed-off-by: Alexei Starovoitov <ast@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ kernel/bpf/verifier.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
+index bb54f1f4fafba..da90f565317d4 100644
+--- a/kernel/bpf/verifier.c
++++ b/kernel/bpf/verifier.c
+@@ -15500,7 +15500,7 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr, bpfptr_t uattr)
+ /* 'struct bpf_verifier_env' can be global, but since it's not small,
+ * allocate/free it every time bpf_check() is called
+ */
+- env = kzalloc(sizeof(struct bpf_verifier_env), GFP_KERNEL);
++ env = kvzalloc(sizeof(struct bpf_verifier_env), GFP_KERNEL);
+ if (!env)
+ return -ENOMEM;
+ log = &env->log;
+@@ -15721,6 +15721,6 @@ int bpf_check(struct bpf_prog **prog, union bpf_attr *attr, bpfptr_t uattr)
+ mutex_unlock(&bpf_verifier_lock);
+ vfree(env->insn_aux_data);
+ err_free_env:
+- kfree(env);
++ kvfree(env);
+ return ret;
+ }
+--
+2.43.0
+
--- /dev/null
+From 7b3e271547708db86b83d83c3bdac3bca9494433 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 6 Oct 2024 09:18:37 +0800
+Subject: crypto: api - Fix liveliness check in crypto_alg_tested
+
+From: Herbert Xu <herbert@gondor.apana.org.au>
+
+[ Upstream commit b81e286ba154a4e0f01a94d99179a97f4ba3e396 ]
+
+As algorithm testing is carried out without holding the main crypto
+lock, it is always possible for the algorithm to go away during the
+test.
+
+So before crypto_alg_tested updates the status of the tested alg,
+it checks whether it's still on the list of all algorithms. This
+is inaccurate because it may be off the main list but still on the
+list of algorithms to be removed.
+
+Updating the algorithm status is safe per se as the larval still
+holds a reference to it. However, killing spawns of other algorithms
+that are of lower priority is clearly a deficiency as it adds
+unnecessary churn.
+
+Fix the test by checking whether the algorithm is dead.
+
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ crypto/algapi.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/crypto/algapi.c b/crypto/algapi.c
+index 5dc9ccdd5a510..206a13f395967 100644
+--- a/crypto/algapi.c
++++ b/crypto/algapi.c
+@@ -341,7 +341,7 @@ void crypto_alg_tested(const char *name, int err)
+ q->cra_flags |= CRYPTO_ALG_DEAD;
+ alg = test->adult;
+
+- if (list_empty(&alg->cra_list))
++ if (crypto_is_dead(alg))
+ goto complete;
+
+ if (err == -ECANCELED)
+--
+2.43.0
+
--- /dev/null
+From 2d50aa477bada01aeb68b798932970f156461475 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 9 Oct 2024 16:38:48 +0800
+Subject: crypto: marvell/cesa - Disable hash algorithms
+
+From: Herbert Xu <herbert@gondor.apana.org.au>
+
+[ Upstream commit e845d2399a00f866f287e0cefbd4fc7d8ef0d2f7 ]
+
+Disable cesa hash algorithms by lowering the priority because they
+appear to be broken when invoked in parallel. This allows them to
+still be tested for debugging purposes.
+
+Reported-by: Klaus Kudielka <klaus.kudielka@gmail.com>
+Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/crypto/marvell/cesa/hash.c | 12 ++++++------
+ 1 file changed, 6 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/crypto/marvell/cesa/hash.c b/drivers/crypto/marvell/cesa/hash.c
+index c72b0672fc710..84c1065092796 100644
+--- a/drivers/crypto/marvell/cesa/hash.c
++++ b/drivers/crypto/marvell/cesa/hash.c
+@@ -947,7 +947,7 @@ struct ahash_alg mv_md5_alg = {
+ .base = {
+ .cra_name = "md5",
+ .cra_driver_name = "mv-md5",
+- .cra_priority = 300,
++ .cra_priority = 0,
+ .cra_flags = CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_ALG_KERN_DRIVER_ONLY,
+@@ -1018,7 +1018,7 @@ struct ahash_alg mv_sha1_alg = {
+ .base = {
+ .cra_name = "sha1",
+ .cra_driver_name = "mv-sha1",
+- .cra_priority = 300,
++ .cra_priority = 0,
+ .cra_flags = CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_ALG_KERN_DRIVER_ONLY,
+@@ -1092,7 +1092,7 @@ struct ahash_alg mv_sha256_alg = {
+ .base = {
+ .cra_name = "sha256",
+ .cra_driver_name = "mv-sha256",
+- .cra_priority = 300,
++ .cra_priority = 0,
+ .cra_flags = CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_ALG_KERN_DRIVER_ONLY,
+@@ -1327,7 +1327,7 @@ struct ahash_alg mv_ahmac_md5_alg = {
+ .base = {
+ .cra_name = "hmac(md5)",
+ .cra_driver_name = "mv-hmac-md5",
+- .cra_priority = 300,
++ .cra_priority = 0,
+ .cra_flags = CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_ALG_KERN_DRIVER_ONLY,
+@@ -1398,7 +1398,7 @@ struct ahash_alg mv_ahmac_sha1_alg = {
+ .base = {
+ .cra_name = "hmac(sha1)",
+ .cra_driver_name = "mv-hmac-sha1",
+- .cra_priority = 300,
++ .cra_priority = 0,
+ .cra_flags = CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_ALG_KERN_DRIVER_ONLY,
+@@ -1469,7 +1469,7 @@ struct ahash_alg mv_ahmac_sha256_alg = {
+ .base = {
+ .cra_name = "hmac(sha256)",
+ .cra_driver_name = "mv-hmac-sha256",
+- .cra_priority = 300,
++ .cra_priority = 0,
+ .cra_flags = CRYPTO_ALG_ASYNC |
+ CRYPTO_ALG_ALLOCATES_MEMORY |
+ CRYPTO_ALG_KERN_DRIVER_ONLY,
+--
+2.43.0
+
--- /dev/null
+From e87b77e605e2449c6d8afb620a2e078616024f92 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 8 Aug 2024 15:06:34 -0500
+Subject: drm/vmwgfx: Limit display layout ioctl array size to
+ VMWGFX_NUM_DISPLAY_UNITS
+
+From: Ian Forbes <ian.forbes@broadcom.com>
+
+[ Upstream commit 28a5dfd4f615539fb22fb6d5c219c199c14e6eb6 ]
+
+Currently the array size is only limited by the largest kmalloc size which
+is incorrect. This change will also return a more specific error message
+than ENOMEM to userspace.
+
+Signed-off-by: Ian Forbes <ian.forbes@broadcom.com>
+Reviewed-by: Zack Rusin <zack.rusin@broadcom.com>
+Reviewed-by: Martin Krastev <martin.krastev@broadcom.com>
+Signed-off-by: Zack Rusin <zack.rusin@broadcom.com>
+Link: https://patchwork.freedesktop.org/patch/msgid/20240808200634.1074083-1-ian.forbes@broadcom.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4 ++--
+ drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 4 +++-
+ drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 3 ---
+ 3 files changed, 5 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+index bca10214e0bf1..abdca2346f1a0 100644
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+@@ -59,7 +59,7 @@
+ #define VMWGFX_DRIVER_MINOR 20
+ #define VMWGFX_DRIVER_PATCHLEVEL 0
+ #define VMWGFX_FIFO_STATIC_SIZE (1024*1024)
+-#define VMWGFX_MAX_DISPLAYS 16
++#define VMWGFX_NUM_DISPLAY_UNITS 8
+ #define VMWGFX_CMD_BOUNCE_INIT_SIZE 32768
+
+ #define VMWGFX_MIN_INITIAL_WIDTH 1280
+@@ -79,7 +79,7 @@
+ #define VMWGFX_NUM_GB_CONTEXT 256
+ #define VMWGFX_NUM_GB_SHADER 20000
+ #define VMWGFX_NUM_GB_SURFACE 32768
+-#define VMWGFX_NUM_GB_SCREEN_TARGET VMWGFX_MAX_DISPLAYS
++#define VMWGFX_NUM_GB_SCREEN_TARGET VMWGFX_NUM_DISPLAY_UNITS
+ #define VMWGFX_NUM_DXCONTEXT 256
+ #define VMWGFX_NUM_DXQUERY 512
+ #define VMWGFX_NUM_MOB (VMWGFX_NUM_GB_CONTEXT +\
+diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+index a8f349e748e56..5210b8084217c 100644
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+@@ -2261,7 +2261,7 @@ int vmw_kms_update_layout_ioctl(struct drm_device *dev, void *data,
+ struct drm_mode_config *mode_config = &dev->mode_config;
+ struct drm_vmw_update_layout_arg *arg =
+ (struct drm_vmw_update_layout_arg *)data;
+- void __user *user_rects;
++ const void __user *user_rects;
+ struct drm_vmw_rect *rects;
+ struct drm_rect *drm_rects;
+ unsigned rects_size;
+@@ -2273,6 +2273,8 @@ int vmw_kms_update_layout_ioctl(struct drm_device *dev, void *data,
+ VMWGFX_MIN_INITIAL_HEIGHT};
+ vmw_du_update_layout(dev_priv, 1, &def_rect);
+ return 0;
++ } else if (arg->num_outputs > VMWGFX_NUM_DISPLAY_UNITS) {
++ return -E2BIG;
+ }
+
+ rects_size = arg->num_outputs * sizeof(struct drm_vmw_rect);
+diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+index 1099de1ece4b3..a2a294841df41 100644
+--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
++++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+@@ -199,9 +199,6 @@ struct vmw_kms_dirty {
+ s32 unit_y2;
+ };
+
+-#define VMWGFX_NUM_DISPLAY_UNITS 8
+-
+-
+ #define vmw_framebuffer_to_vfb(x) \
+ container_of(x, struct vmw_framebuffer, base)
+ #define vmw_framebuffer_to_vfbs(x) \
+--
+2.43.0
+
--- /dev/null
+From 738a870b2dd1d392013a016e1db316435af00f07 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 7 Oct 2024 12:08:03 +0800
+Subject: HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad
+
+From: WangYuli <wangyuli@uniontech.com>
+
+[ Upstream commit 7a5ab8071114344f62a8b1e64ed3452a77257d76 ]
+
+The behavior of HONOR MagicBook Art 14 touchpad is not consistent
+after reboots, as sometimes it reports itself as a touchpad, and
+sometimes as a mouse.
+
+Similarly to GLO-GXXX it is possible to call MT_QUIRK_FORCE_GET_FEATURE as a
+workaround to force set feature in mt_set_input_mode() for such special touchpad
+device.
+
+[jkosina@suse.com: reword changelog a little bit]
+Link: https://gitlab.freedesktop.org/libinput/libinput/-/issues/1040
+Signed-off-by: Wentao Guan <guanwentao@uniontech.com>
+Signed-off-by: WangYuli <wangyuli@uniontech.com>
+Reviewed-by: Benjamin Tissoires <bentiss@kernel.org>
+Signed-off-by: Jiri Kosina <jkosina@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/hid/hid-multitouch.c | 5 +++++
+ 1 file changed, 5 insertions(+)
+
+diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
+index 7584e5a3aafeb..c2d79b2d6cdd2 100644
+--- a/drivers/hid/hid-multitouch.c
++++ b/drivers/hid/hid-multitouch.c
+@@ -2093,6 +2093,11 @@ static const struct hid_device_id mt_devices[] = {
+ HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
+ 0x347d, 0x7853) },
+
++ /* HONOR MagicBook Art 14 touchpad */
++ { .driver_data = MT_CLS_VTL,
++ HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
++ 0x35cc, 0x0104) },
++
+ /* Ilitek dual touch panel */
+ { .driver_data = MT_CLS_NSMU,
+ MT_USB_DEVICE(USB_VENDOR_ID_ILITEK,
+--
+2.43.0
+
--- /dev/null
+From e48678a4f99d0312567b89f2b79c5f89decf7bc6 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Sun, 6 Oct 2024 10:12:23 +0200
+Subject: HID: multitouch: Add support for B2402FVA track point
+
+From: Stefan Blum <stefanblum2004@gmail.com>
+
+[ Upstream commit 1a5cbb526ec4b885177d06a8bc04f38da7dbb1d9 ]
+
+By default the track point does not work on the Asus Expertbook B2402FVA.
+
+From libinput record i got the ID of the track point device:
+ evdev:
+ # Name: ASUE1201:00 04F3:32AE
+ # ID: bus 0x18 vendor 0x4f3 product 0x32ae version 0x100
+
+I found that the track point is functional, when i set the
+MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU class for the reported device.
+
+Signed-off-by: Stefan Blum <stefan.blum@gmail.com>
+Signed-off-by: Jiri Kosina <jkosina@suse.com>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/hid/hid-multitouch.c | 4 ++++
+ 1 file changed, 4 insertions(+)
+
+diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
+index e7199ae2e3d91..7584e5a3aafeb 100644
+--- a/drivers/hid/hid-multitouch.c
++++ b/drivers/hid/hid-multitouch.c
+@@ -2020,6 +2020,10 @@ static const struct hid_device_id mt_devices[] = {
+ HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
+ USB_VENDOR_ID_ELAN, 0x3148) },
+
++ { .driver_data = MT_CLS_WIN_8_FORCE_MULTI_INPUT_NSMU,
++ HID_DEVICE(BUS_I2C, HID_GROUP_MULTITOUCH_WIN_8,
++ USB_VENDOR_ID_ELAN, 0x32ae) },
++
+ /* Elitegroup panel */
+ { .driver_data = MT_CLS_SERIAL,
+ MT_USB_DEVICE(USB_VENDOR_ID_ELITEGROUP,
+--
+2.43.0
+
--- /dev/null
+From a4d696a161336691f882ebfab1d12d11304c5a1e Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 25 Sep 2024 21:44:15 +0300
+Subject: irqchip/ocelot: Fix trigger register address
+
+From: Sergey Matsievskiy <matsievskiysv@gmail.com>
+
+[ Upstream commit 9e9c4666abb5bb444dac37e2d7eb5250c8d52a45 ]
+
+Controllers, supported by this driver, have two sets of registers:
+
+ * (main) interrupt registers control peripheral interrupt sources.
+
+ * device interrupt registers configure per-device (network interface)
+ interrupts and act as an extra stage before the main interrupt
+ registers.
+
+In the driver unmask code, device trigger registers are used in the mask
+calculation of the main interrupt sticky register, mixing two kinds of
+registers.
+
+Use the main interrupt trigger register instead.
+
+Signed-off-by: Sergey Matsievskiy <matsievskiysv@gmail.com>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+Link: https://lore.kernel.org/all/20240925184416.54204-2-matsievskiysv@gmail.com
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/irqchip/irq-mscc-ocelot.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/drivers/irqchip/irq-mscc-ocelot.c b/drivers/irqchip/irq-mscc-ocelot.c
+index 4d0c3532dbe73..c19ab379e8c5e 100644
+--- a/drivers/irqchip/irq-mscc-ocelot.c
++++ b/drivers/irqchip/irq-mscc-ocelot.c
+@@ -37,7 +37,7 @@ static struct chip_props ocelot_props = {
+ .reg_off_ena_clr = 0x1c,
+ .reg_off_ena_set = 0x20,
+ .reg_off_ident = 0x38,
+- .reg_off_trigger = 0x5c,
++ .reg_off_trigger = 0x4,
+ .n_irq = 24,
+ };
+
+@@ -70,7 +70,7 @@ static struct chip_props jaguar2_props = {
+ .reg_off_ena_clr = 0x1c,
+ .reg_off_ena_set = 0x20,
+ .reg_off_ident = 0x38,
+- .reg_off_trigger = 0x5c,
++ .reg_off_trigger = 0x4,
+ .n_irq = 29,
+ };
+
+--
+2.43.0
+
--- /dev/null
+From 5f1f50fcbb793495ab320bdb4beb603bf965c2ce Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 14 Oct 2024 17:11:00 +0100
+Subject: kasan: Disable Software Tag-Based KASAN with GCC
+
+From: Will Deacon <will@kernel.org>
+
+[ Upstream commit 7aed6a2c51ffc97a126e0ea0c270fab7af97ae18 ]
+
+Syzbot reports a KASAN failure early during boot on arm64 when building
+with GCC 12.2.0 and using the Software Tag-Based KASAN mode:
+
+ | BUG: KASAN: invalid-access in smp_build_mpidr_hash arch/arm64/kernel/setup.c:133 [inline]
+ | BUG: KASAN: invalid-access in setup_arch+0x984/0xd60 arch/arm64/kernel/setup.c:356
+ | Write of size 4 at addr 03ff800086867e00 by task swapper/0
+ | Pointer tag: [03], memory tag: [fe]
+
+Initial triage indicates that the report is a false positive and a
+thorough investigation of the crash by Mark Rutland revealed the root
+cause to be a bug in GCC:
+
+ > When GCC is passed `-fsanitize=hwaddress` or
+ > `-fsanitize=kernel-hwaddress` it ignores
+ > `__attribute__((no_sanitize_address))`, and instruments functions
+ > we require are not instrumented.
+ >
+ > [...]
+ >
+ > All versions [of GCC] I tried were broken, from 11.3.0 to 14.2.0
+ > inclusive.
+ >
+ > I think we have to disable KASAN_SW_TAGS with GCC until this is
+ > fixed
+
+Disable Software Tag-Based KASAN when building with GCC by making
+CC_HAS_KASAN_SW_TAGS depend on !CC_IS_GCC.
+
+Cc: Andrey Konovalov <andreyknvl@gmail.com>
+Suggested-by: Mark Rutland <mark.rutland@arm.com>
+Reported-by: syzbot+908886656a02769af987@syzkaller.appspotmail.com
+Link: https://lore.kernel.org/r/000000000000f362e80620e27859@google.com
+Link: https://lore.kernel.org/r/ZvFGwKfoC4yVjN_X@J2N7QTR9R3
+Link: https://bugzilla.kernel.org/show_bug.cgi?id=218854
+Reviewed-by: Andrey Konovalov <andreyknvl@gmail.com>
+Acked-by: Mark Rutland <mark.rutland@arm.com>
+Link: https://lore.kernel.org/r/20241014161100.18034-1-will@kernel.org
+Signed-off-by: Will Deacon <will@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ lib/Kconfig.kasan | 7 +++++--
+ 1 file changed, 5 insertions(+), 2 deletions(-)
+
+diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan
+index ca09b1cf8ee9d..34420eb1cbfe1 100644
+--- a/lib/Kconfig.kasan
++++ b/lib/Kconfig.kasan
+@@ -22,8 +22,11 @@ config ARCH_DISABLE_KASAN_INLINE
+ config CC_HAS_KASAN_GENERIC
+ def_bool $(cc-option, -fsanitize=kernel-address)
+
++# GCC appears to ignore no_sanitize_address when -fsanitize=kernel-hwaddress
++# is passed. See https://bugzilla.kernel.org/show_bug.cgi?id=218854 (and
++# the linked LKML thread) for more details.
+ config CC_HAS_KASAN_SW_TAGS
+- def_bool $(cc-option, -fsanitize=kernel-hwaddress)
++ def_bool !CC_IS_GCC && $(cc-option, -fsanitize=kernel-hwaddress)
+
+ # This option is only required for software KASAN modes.
+ # Old GCC versions do not have proper support for no_sanitize_address.
+@@ -91,7 +94,7 @@ config KASAN_SW_TAGS
+ help
+ Enables Software Tag-Based KASAN.
+
+- Requires GCC 11+ or Clang.
++ Requires Clang.
+
+ Supported only on arm64 CPUs and relies on Top Byte Ignore.
+
+--
+2.43.0
+
--- /dev/null
+From 8ede27b0bbb3f9b7a87991ae4395601c2f2ee2e0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Mon, 7 Oct 2024 14:33:24 -0500
+Subject: nvme: disable CC.CRIME (NVME_CC_CRIME)
+
+From: Greg Joyce <gjoyce@linux.ibm.com>
+
+[ Upstream commit 0ce96a6708f34280a536263ee5c67e20c433dcce ]
+
+Disable NVME_CC_CRIME so that CSTS.RDY indicates that the media
+is ready and able to handle commands without returning
+NVME_SC_ADMIN_COMMAND_MEDIA_NOT_READY.
+
+Signed-off-by: Greg Joyce <gjoyce@linux.ibm.com>
+Reviewed-by: Nilay Shroff <nilay@linux.ibm.com>
+Tested-by: Nilay Shroff <nilay@linux.ibm.com>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nvme/host/core.c | 14 ++++++++------
+ 1 file changed, 8 insertions(+), 6 deletions(-)
+
+diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
+index 0729ab5430725..dc25d91891327 100644
+--- a/drivers/nvme/host/core.c
++++ b/drivers/nvme/host/core.c
+@@ -2394,8 +2394,13 @@ int nvme_enable_ctrl(struct nvme_ctrl *ctrl)
+ else
+ ctrl->ctrl_config = NVME_CC_CSS_NVM;
+
+- if (ctrl->cap & NVME_CAP_CRMS_CRWMS && ctrl->cap & NVME_CAP_CRMS_CRIMS)
+- ctrl->ctrl_config |= NVME_CC_CRIME;
++ /*
++ * Setting CRIME results in CSTS.RDY before the media is ready. This
++ * makes it possible for media related commands to return the error
++ * NVME_SC_ADMIN_COMMAND_MEDIA_NOT_READY. Until the driver is
++ * restructured to handle retries, disable CC.CRIME.
++ */
++ ctrl->ctrl_config &= ~NVME_CC_CRIME;
+
+ ctrl->ctrl_config |= (NVME_CTRL_PAGE_SHIFT - 12) << NVME_CC_MPS_SHIFT;
+ ctrl->ctrl_config |= NVME_CC_AMS_RR | NVME_CC_SHN_NONE;
+@@ -2430,10 +2435,7 @@ int nvme_enable_ctrl(struct nvme_ctrl *ctrl)
+ * devices are known to get this wrong. Use the larger of the
+ * two values.
+ */
+- if (ctrl->ctrl_config & NVME_CC_CRIME)
+- ready_timeout = NVME_CRTO_CRIMT(crto);
+- else
+- ready_timeout = NVME_CRTO_CRWMT(crto);
++ ready_timeout = NVME_CRTO_CRWMT(crto);
+
+ if (ready_timeout < timeout)
+ dev_warn_once(ctrl->device, "bad crto:%x cap:%llx\n",
+--
+2.43.0
+
--- /dev/null
+From 94e0d57b1c74287318fc37cdae24f943e4da088f Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 16 Oct 2024 08:33:15 +0530
+Subject: nvme: make keep-alive synchronous operation
+
+From: Nilay Shroff <nilay@linux.ibm.com>
+
+[ Upstream commit d06923670b5a5f609603d4a9fee4dec02d38de9c ]
+
+The nvme keep-alive operation, which executes at a periodic interval,
+could potentially sneak in while shutting down a fabric controller.
+This may lead to a race between the fabric controller admin queue
+destroy code path (invoked while shutting down controller) and hw/hctx
+queue dispatcher called from the nvme keep-alive async request queuing
+operation. This race could lead to the kernel crash shown below:
+
+Call Trace:
+ autoremove_wake_function+0x0/0xbc (unreliable)
+ __blk_mq_sched_dispatch_requests+0x114/0x24c
+ blk_mq_sched_dispatch_requests+0x44/0x84
+ blk_mq_run_hw_queue+0x140/0x220
+ nvme_keep_alive_work+0xc8/0x19c [nvme_core]
+ process_one_work+0x200/0x4e0
+ worker_thread+0x340/0x504
+ kthread+0x138/0x140
+ start_kernel_thread+0x14/0x18
+
+While shutting down fabric controller, if nvme keep-alive request sneaks
+in then it would be flushed off. The nvme_keep_alive_end_io function is
+then invoked to handle the end of the keep-alive operation which
+decrements the admin->q_usage_counter and assuming this is the last/only
+request in the admin queue then the admin->q_usage_counter becomes zero.
+If that happens then blk-mq destroy queue operation (blk_mq_destroy_
+queue()) which could be potentially running simultaneously on another
+cpu (as this is the controller shutdown code path) would forward
+progress and deletes the admin queue. So, now from this point onward
+we are not supposed to access the admin queue resources. However the
+issue here's that the nvme keep-alive thread running hw/hctx queue
+dispatch operation hasn't yet finished its work and so it could still
+potentially access the admin queue resource while the admin queue had
+been already deleted and that causes the above crash.
+
+This fix helps avoid the observed crash by implementing keep-alive as a
+synchronous operation so that we decrement admin->q_usage_counter only
+after keep-alive command finished its execution and returns the command
+status back up to its caller (blk_execute_rq()). This would ensure that
+fabric shutdown code path doesn't destroy the fabric admin queue until
+keep-alive request finished execution and also keep-alive thread is not
+running hw/hctx queue dispatch operation.
+
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Nilay Shroff <nilay@linux.ibm.com>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nvme/host/core.c | 17 +++++++----------
+ 1 file changed, 7 insertions(+), 10 deletions(-)
+
+diff --git a/drivers/nvme/host/core.c b/drivers/nvme/host/core.c
+index dc25d91891327..92ffeb6605618 100644
+--- a/drivers/nvme/host/core.c
++++ b/drivers/nvme/host/core.c
+@@ -1231,10 +1231,9 @@ static void nvme_queue_keep_alive_work(struct nvme_ctrl *ctrl)
+ nvme_keep_alive_work_period(ctrl));
+ }
+
+-static enum rq_end_io_ret nvme_keep_alive_end_io(struct request *rq,
+- blk_status_t status)
++static void nvme_keep_alive_finish(struct request *rq,
++ blk_status_t status, struct nvme_ctrl *ctrl)
+ {
+- struct nvme_ctrl *ctrl = rq->end_io_data;
+ unsigned long flags;
+ bool startka = false;
+ unsigned long rtt = jiffies - (rq->deadline - rq->timeout);
+@@ -1252,13 +1251,11 @@ static enum rq_end_io_ret nvme_keep_alive_end_io(struct request *rq,
+ delay = 0;
+ }
+
+- blk_mq_free_request(rq);
+-
+ if (status) {
+ dev_err(ctrl->device,
+ "failed nvme_keep_alive_end_io error=%d\n",
+ status);
+- return RQ_END_IO_NONE;
++ return;
+ }
+
+ ctrl->ka_last_check_time = jiffies;
+@@ -1270,7 +1267,6 @@ static enum rq_end_io_ret nvme_keep_alive_end_io(struct request *rq,
+ spin_unlock_irqrestore(&ctrl->lock, flags);
+ if (startka)
+ queue_delayed_work(nvme_wq, &ctrl->ka_work, delay);
+- return RQ_END_IO_NONE;
+ }
+
+ static void nvme_keep_alive_work(struct work_struct *work)
+@@ -1279,6 +1275,7 @@ static void nvme_keep_alive_work(struct work_struct *work)
+ struct nvme_ctrl, ka_work);
+ bool comp_seen = ctrl->comp_seen;
+ struct request *rq;
++ blk_status_t status;
+
+ ctrl->ka_last_check_time = jiffies;
+
+@@ -1301,9 +1298,9 @@ static void nvme_keep_alive_work(struct work_struct *work)
+ nvme_init_request(rq, &ctrl->ka_cmd);
+
+ rq->timeout = ctrl->kato * HZ;
+- rq->end_io = nvme_keep_alive_end_io;
+- rq->end_io_data = ctrl;
+- blk_execute_rq_nowait(rq, false);
++ status = blk_execute_rq(rq, false);
++ nvme_keep_alive_finish(rq, status, ctrl);
++ blk_mq_free_request(rq);
+ }
+
+ static void nvme_start_keep_alive(struct nvme_ctrl *ctrl)
+--
+2.43.0
+
--- /dev/null
+From 2f209562d84e21d38000dff355bba6c7477b4fd3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Tue, 15 Oct 2024 07:30:17 -0700
+Subject: nvme-multipath: defer partition scanning
+
+From: Keith Busch <kbusch@kernel.org>
+
+[ Upstream commit 1f021341eef41e77a633186e9be5223de2ce5d48 ]
+
+We need to suppress the partition scan from occuring within the
+controller's scan_work context. If a path error occurs here, the IO will
+wait until a path becomes available or all paths are torn down, but that
+action also occurs within scan_work, so it would deadlock. Defer the
+partion scan to a different context that does not block scan_work.
+
+Reported-by: Hannes Reinecke <hare@suse.de>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nvme/host/multipath.c | 33 +++++++++++++++++++++++++++++++++
+ drivers/nvme/host/nvme.h | 1 +
+ 2 files changed, 34 insertions(+)
+
+diff --git a/drivers/nvme/host/multipath.c b/drivers/nvme/host/multipath.c
+index 93ada8941a4c5..43b89c7d585f0 100644
+--- a/drivers/nvme/host/multipath.c
++++ b/drivers/nvme/host/multipath.c
+@@ -463,6 +463,20 @@ static int nvme_add_ns_head_cdev(struct nvme_ns_head *head)
+ return ret;
+ }
+
++static void nvme_partition_scan_work(struct work_struct *work)
++{
++ struct nvme_ns_head *head =
++ container_of(work, struct nvme_ns_head, partition_scan_work);
++
++ if (WARN_ON_ONCE(!test_and_clear_bit(GD_SUPPRESS_PART_SCAN,
++ &head->disk->state)))
++ return;
++
++ mutex_lock(&head->disk->open_mutex);
++ bdev_disk_changed(head->disk, false);
++ mutex_unlock(&head->disk->open_mutex);
++}
++
+ static void nvme_requeue_work(struct work_struct *work)
+ {
+ struct nvme_ns_head *head =
+@@ -489,6 +503,7 @@ int nvme_mpath_alloc_disk(struct nvme_ctrl *ctrl, struct nvme_ns_head *head)
+ bio_list_init(&head->requeue_list);
+ spin_lock_init(&head->requeue_lock);
+ INIT_WORK(&head->requeue_work, nvme_requeue_work);
++ INIT_WORK(&head->partition_scan_work, nvme_partition_scan_work);
+
+ /*
+ * Add a multipath node if the subsystems supports multiple controllers.
+@@ -504,6 +519,16 @@ int nvme_mpath_alloc_disk(struct nvme_ctrl *ctrl, struct nvme_ns_head *head)
+ return -ENOMEM;
+ head->disk->fops = &nvme_ns_head_ops;
+ head->disk->private_data = head;
++
++ /*
++ * We need to suppress the partition scan from occuring within the
++ * controller's scan_work context. If a path error occurs here, the IO
++ * will wait until a path becomes available or all paths are torn down,
++ * but that action also occurs within scan_work, so it would deadlock.
++ * Defer the partion scan to a different context that does not block
++ * scan_work.
++ */
++ set_bit(GD_SUPPRESS_PART_SCAN, &head->disk->state);
+ sprintf(head->disk->disk_name, "nvme%dn%d",
+ ctrl->subsys->instance, head->instance);
+
+@@ -552,6 +577,7 @@ static void nvme_mpath_set_live(struct nvme_ns *ns)
+ return;
+ }
+ nvme_add_ns_head_cdev(head);
++ kblockd_schedule_work(&head->partition_scan_work);
+ }
+
+ mutex_lock(&head->lock);
+@@ -851,6 +877,12 @@ void nvme_mpath_shutdown_disk(struct nvme_ns_head *head)
+ kblockd_schedule_work(&head->requeue_work);
+ if (test_bit(NVME_NSHEAD_DISK_LIVE, &head->flags)) {
+ nvme_cdev_del(&head->cdev, &head->cdev_device);
++ /*
++ * requeue I/O after NVME_NSHEAD_DISK_LIVE has been cleared
++ * to allow multipath to fail all I/O.
++ */
++ synchronize_srcu(&head->srcu);
++ kblockd_schedule_work(&head->requeue_work);
+ del_gendisk(head->disk);
+ }
+ }
+@@ -862,6 +894,7 @@ void nvme_mpath_remove_disk(struct nvme_ns_head *head)
+ /* make sure all pending bios are cleaned up */
+ kblockd_schedule_work(&head->requeue_work);
+ flush_work(&head->requeue_work);
++ flush_work(&head->partition_scan_work);
+ put_disk(head->disk);
+ }
+
+diff --git a/drivers/nvme/host/nvme.h b/drivers/nvme/host/nvme.h
+index 5f8a146b70148..0f49b779dec65 100644
+--- a/drivers/nvme/host/nvme.h
++++ b/drivers/nvme/host/nvme.h
+@@ -460,6 +460,7 @@ struct nvme_ns_head {
+ struct bio_list requeue_list;
+ spinlock_t requeue_lock;
+ struct work_struct requeue_work;
++ struct work_struct partition_scan_work;
+ struct mutex lock;
+ unsigned long flags;
+ #define NVME_NSHEAD_DISK_LIVE 0
+--
+2.43.0
+
--- /dev/null
+From 526d1eee75b4e11d986289ca29cc9543c79d72a0 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Wed, 2 Oct 2024 13:51:41 +0900
+Subject: nvme: tcp: avoid race between queue_lock lock and destroy
+
+From: Hannes Reinecke <hare@suse.de>
+
+[ Upstream commit 782373ba27660ba7d330208cf5509ece6feb4545 ]
+
+Commit 76d54bf20cdc ("nvme-tcp: don't access released socket during
+error recovery") added a mutex_lock() call for the queue->queue_lock
+in nvme_tcp_get_address(). However, the mutex_lock() races with
+mutex_destroy() in nvme_tcp_free_queue(), and causes the WARN below.
+
+DEBUG_LOCKS_WARN_ON(lock->magic != lock)
+WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 __mutex_lock+0xcf0/0x1220
+Modules linked in: nvmet_tcp nvmet nvme_tcp nvme_fabrics iw_cm ib_cm ib_core pktcdvd nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables qrtr sunrpc ppdev 9pnet_virtio 9pnet pcspkr netfs parport_pc parport e1000 i2c_piix4 i2c_smbus loop fuse nfnetlink zram bochs drm_vram_helper drm_ttm_helper ttm drm_kms_helper xfs drm sym53c8xx floppy nvme scsi_transport_spi nvme_core nvme_auth serio_raw ata_generic pata_acpi dm_multipath qemu_fw_cfg [last unloaded: ib_uverbs]
+CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319
+Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
+RIP: 0010:__mutex_lock+0xcf0/0x1220
+Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1
+RSP: 0018:ffff88811305f760 EFLAGS: 00010286
+RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000
+RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001
+RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341
+R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000
+R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058
+FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000
+CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0
+DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+Call Trace:
+ <TASK>
+ ? __warn.cold+0x5b/0x1af
+ ? __mutex_lock+0xcf0/0x1220
+ ? report_bug+0x1ec/0x390
+ ? handle_bug+0x3c/0x80
+ ? exc_invalid_op+0x13/0x40
+ ? asm_exc_invalid_op+0x16/0x20
+ ? __mutex_lock+0xcf0/0x1220
+ ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]
+ ? __pfx___mutex_lock+0x10/0x10
+ ? __lock_acquire+0xd6a/0x59e0
+ ? nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]
+ nvme_tcp_get_address+0xc2/0x1e0 [nvme_tcp]
+ ? __pfx_nvme_tcp_get_address+0x10/0x10 [nvme_tcp]
+ nvme_sysfs_show_address+0x81/0xc0 [nvme_core]
+ dev_attr_show+0x42/0x80
+ ? __asan_memset+0x1f/0x40
+ sysfs_kf_seq_show+0x1f0/0x370
+ seq_read_iter+0x2cb/0x1130
+ ? rw_verify_area+0x3b1/0x590
+ ? __mutex_lock+0x433/0x1220
+ vfs_read+0x6a6/0xa20
+ ? lockdep_hardirqs_on+0x78/0x100
+ ? __pfx_vfs_read+0x10/0x10
+ ksys_read+0xf7/0x1d0
+ ? __pfx_ksys_read+0x10/0x10
+ ? __x64_sys_openat+0x105/0x1d0
+ do_syscall_64+0x93/0x180
+ ? lockdep_hardirqs_on_prepare+0x16d/0x400
+ ? do_syscall_64+0x9f/0x180
+ ? lockdep_hardirqs_on+0x78/0x100
+ ? do_syscall_64+0x9f/0x180
+ ? __pfx_ksys_read+0x10/0x10
+ ? lockdep_hardirqs_on_prepare+0x16d/0x400
+ ? do_syscall_64+0x9f/0x180
+ ? lockdep_hardirqs_on+0x78/0x100
+ ? do_syscall_64+0x9f/0x180
+ ? lockdep_hardirqs_on_prepare+0x16d/0x400
+ ? do_syscall_64+0x9f/0x180
+ ? lockdep_hardirqs_on+0x78/0x100
+ ? do_syscall_64+0x9f/0x180
+ ? lockdep_hardirqs_on_prepare+0x16d/0x400
+ ? do_syscall_64+0x9f/0x180
+ ? lockdep_hardirqs_on+0x78/0x100
+ ? do_syscall_64+0x9f/0x180
+ ? lockdep_hardirqs_on_prepare+0x16d/0x400
+ ? do_syscall_64+0x9f/0x180
+ ? lockdep_hardirqs_on+0x78/0x100
+ ? do_syscall_64+0x9f/0x180
+ ? do_syscall_64+0x9f/0x180
+ entry_SYSCALL_64_after_hwframe+0x76/0x7e
+RIP: 0033:0x7f9713f55cfa
+Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 41 89 c0 8b 7d f8 31 c0 0f 05 <48> 3d 00 f0 ff ff 77 2e 44 89 c7 48 89 45 f8 e8 42 75 f8 ff 48 8b
+RSP: 002b:00007ffd7f512e70 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
+RAX: ffffffffffffffda RBX: 000055c38f316859 RCX: 00007f9713f55cfa
+RDX: 0000000000000fff RSI: 00007ffd7f512eb0 RDI: 0000000000000011
+RBP: 00007ffd7f512e90 R08: 0000000000000000 R09: 00000000ffffffff
+R10: 0000000000000000 R11: 0000000000000246 R12: 000055c38f317148
+R13: 0000000000000000 R14: 00007f96f4004f30 R15: 000055c3b6b623c0
+ </TASK>
+
+The WARN is observed when the blktests test case nvme/014 is repeated
+with tcp transport. It is rare, and 200 times repeat is required to
+recreate in some test environments.
+
+To avoid the WARN, check the NVME_TCP_Q_LIVE flag before locking
+queue->queue_lock. The flag is cleared long time before the lock gets
+destroyed.
+
+Signed-off-by: Hannes Reinecke <hare@suse.de>
+Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ drivers/nvme/host/tcp.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
+index f2fedd25915f9..29489c2c52fb9 100644
+--- a/drivers/nvme/host/tcp.c
++++ b/drivers/nvme/host/tcp.c
+@@ -2495,10 +2495,11 @@ static int nvme_tcp_get_address(struct nvme_ctrl *ctrl, char *buf, int size)
+
+ len = nvmf_get_address(ctrl, buf, size);
+
++ if (!test_bit(NVME_TCP_Q_LIVE, &queue->flags))
++ return len;
++
+ mutex_lock(&queue->queue_lock);
+
+- if (!test_bit(NVME_TCP_Q_LIVE, &queue->flags))
+- goto done;
+ ret = kernel_getsockname(queue->sock, (struct sockaddr *)&src_addr);
+ if (ret > 0) {
+ if (len > 0)
+@@ -2506,7 +2507,7 @@ static int nvme_tcp_get_address(struct nvme_ctrl *ctrl, char *buf, int size)
+ len += scnprintf(buf + len, size - len, "%ssrc_addr=%pISc\n",
+ (len) ? "," : "", &src_addr);
+ }
+-done:
++
+ mutex_unlock(&queue->queue_lock);
+
+ return len;
+--
+2.43.0
+
--- /dev/null
+From 95a0ed1626069b822c4ee8678b09acff7f994af3 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Fri, 20 Sep 2024 19:35:20 +1000
+Subject: powerpc/powernv: Free name on error in opal_event_init()
+
+From: Michael Ellerman <mpe@ellerman.id.au>
+
+[ Upstream commit cf8989d20d64ad702a6210c11a0347ebf3852aa7 ]
+
+In opal_event_init() if request_irq() fails name is not freed, leading
+to a memory leak. The code only runs at boot time, there's no way for a
+user to trigger it, so there's no security impact.
+
+Fix the leak by freeing name in the error path.
+
+Reported-by: 2639161967 <2639161967@qq.com>
+Closes: https://lore.kernel.org/linuxppc-dev/87wmjp3wig.fsf@mail.lhotse
+Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
+Link: https://patch.msgid.link/20240920093520.67997-1-mpe@ellerman.id.au
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ arch/powerpc/platforms/powernv/opal-irqchip.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+diff --git a/arch/powerpc/platforms/powernv/opal-irqchip.c b/arch/powerpc/platforms/powernv/opal-irqchip.c
+index 391f505352007..e9849d70aee4a 100644
+--- a/arch/powerpc/platforms/powernv/opal-irqchip.c
++++ b/arch/powerpc/platforms/powernv/opal-irqchip.c
+@@ -282,6 +282,7 @@ int __init opal_event_init(void)
+ name, NULL);
+ if (rc) {
+ pr_warn("Error %d requesting OPAL irq %d\n", rc, (int)r->start);
++ kfree(name);
+ continue;
+ }
+ }
+--
+2.43.0
+
revert-bluetooth-af_bluetooth-fix-deadlock.patch
revert-bluetooth-hci_core-fix-possible-buffer-overflow.patch
revert-bluetooth-hci_conn-consolidate-code-for-aborting-connections.patch
+9p-avoid-creating-multiple-slab-caches-with-the-same.patch
+irqchip-ocelot-fix-trigger-register-address.patch
+nvme-tcp-avoid-race-between-queue_lock-lock-and-dest.patch
+block-fix-elevator_get_default-checking-for-null-q-t.patch
+hid-multitouch-add-support-for-b2402fva-track-point.patch
+hid-multitouch-add-quirk-for-honor-magicbook-art-14-.patch
+nvme-disable-cc.crime-nvme_cc_crime.patch
+bpf-use-kvzmalloc-to-allocate-bpf-verifier-environme.patch
+crypto-api-fix-liveliness-check-in-crypto_alg_tested.patch
+crypto-marvell-cesa-disable-hash-algorithms.patch
+sound-make-config_snd-depend-on-indirect_iomem-inste.patch
+drm-vmwgfx-limit-display-layout-ioctl-array-size-to-.patch
+kasan-disable-software-tag-based-kasan-with-gcc.patch
+nvme-multipath-defer-partition-scanning.patch
+powerpc-powernv-free-name-on-error-in-opal_event_ini.patch
+nvme-make-keep-alive-synchronous-operation.patch
--- /dev/null
+From 2bd4adcdf43d92cb19392cd617b22767b540a436 Mon Sep 17 00:00:00 2001
+From: Sasha Levin <sashal@kernel.org>
+Date: Thu, 10 Oct 2024 14:46:01 +0200
+Subject: sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML
+
+From: Julian Vetter <jvetter@kalrayinc.com>
+
+[ Upstream commit ad6639f143a0b42d7fb110ad14f5949f7c218890 ]
+
+When building for the UM arch and neither INDIRECT_IOMEM=y, nor
+HAS_IOMEM=y is selected, it will fall back to the implementations from
+asm-generic/io.h for IO memcpy. But these fall-back functions just do a
+memcpy. So, instead of depending on UML, add dependency on 'HAS_IOMEM ||
+INDIRECT_IOMEM'.
+
+Reviewed-by: Yann Sionneau <ysionneau@kalrayinc.com>
+Signed-off-by: Julian Vetter <jvetter@kalrayinc.com>
+Link: https://patch.msgid.link/20241010124601.700528-1-jvetter@kalrayinc.com
+Signed-off-by: Takashi Iwai <tiwai@suse.de>
+Signed-off-by: Sasha Levin <sashal@kernel.org>
+---
+ sound/Kconfig | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/sound/Kconfig b/sound/Kconfig
+index 1903c35d799e1..5848eedcc3c9f 100644
+--- a/sound/Kconfig
++++ b/sound/Kconfig
+@@ -1,7 +1,7 @@
+ # SPDX-License-Identifier: GPL-2.0-only
+ menuconfig SOUND
+ tristate "Sound card support"
+- depends on HAS_IOMEM || UML
++ depends on HAS_IOMEM || INDIRECT_IOMEM
+ help
+ If you have a sound card in your computer, i.e. if it can say more
+ than an occasional beep, say Y.
+--
+2.43.0
+
projects / thirdparty / kernel / stable-queue.git / commitdiff
