From: Sasha Levin Date: Thu, 14 Nov 2024 12:39:18 +0000 (-0500) Subject: Fixes for 6.1 X-Git-Tag: v4.19.324~32 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=a082c7ef13ff7636a52441acfc1ffdf6869f3198;p=thirdparty%2Fkernel%2Fstable-queue.git Fixes for 6.1 Signed-off-by: Sasha Levin --- diff --git a/queue-6.1/9p-avoid-creating-multiple-slab-caches-with-the-same.patch b/queue-6.1/9p-avoid-creating-multiple-slab-caches-with-the-same.patch new file mode 100644 index 00000000000..3202637e373 --- /dev/null +++ b/queue-6.1/9p-avoid-creating-multiple-slab-caches-with-the-same.patch @@ -0,0 +1,62 @@ +From 4ee5d556c5c15eaa7c18c3f7725bd4e2eff8edf5 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 7 Aug 2024 10:47:25 +0100 +Subject: 9p: Avoid creating multiple slab caches with the same name + +From: Pedro Falcato + +[ 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 +Reported-by: syzbot+3c5d43e97993e1fa612b@syzkaller.appspotmail.com +Message-ID: <20240807094725.2193423-1-pedro.falcato@gmail.com> +Signed-off-by: Dominique Martinet +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/block-fix-elevator_get_default-checking-for-null-q-t.patch b/queue-6.1/block-fix-elevator_get_default-checking-for-null-q-t.patch new file mode 100644 index 00000000000..5bbdd81cc12 --- /dev/null +++ b/queue-6.1/block-fix-elevator_get_default-checking-for-null-q-t.patch @@ -0,0 +1,50 @@ +From 08742f8e7e81b6b6bdfb5a94d9dcd5413cc4901f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 7 Oct 2024 16:44:16 +0530 +Subject: block: Fix elevator_get_default() checking for NULL q->tag_set + +From: SurajSonawane2415 + +[ 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 +Link: https://lore.kernel.org/r/20241007111416.13814-1-surajsonawane0215@gmail.com +Signed-off-by: Jens Axboe +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/bpf-use-kvzmalloc-to-allocate-bpf-verifier-environme.patch b/queue-6.1/bpf-use-kvzmalloc-to-allocate-bpf-verifier-environme.patch new file mode 100644 index 00000000000..1d8a441361e --- /dev/null +++ b/queue-6.1/bpf-use-kvzmalloc-to-allocate-bpf-verifier-environme.patch @@ -0,0 +1,52 @@ +From b2d1f1113e2fc90c0523e6a5aff97557f83f050a Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 8 Oct 2024 17:07:35 -0400 +Subject: bpf: use kvzmalloc to allocate BPF verifier environment + +From: Rik van Riel + +[ 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 +Reviewed-by: Shakeel Butt +Link: https://lore.kernel.org/r/20241008170735.16766766@imladris.surriel.com +Signed-off-by: Alexei Starovoitov +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/crypto-api-fix-liveliness-check-in-crypto_alg_tested.patch b/queue-6.1/crypto-api-fix-liveliness-check-in-crypto_alg_tested.patch new file mode 100644 index 00000000000..189d9d597e5 --- /dev/null +++ b/queue-6.1/crypto-api-fix-liveliness-check-in-crypto_alg_tested.patch @@ -0,0 +1,47 @@ +From 7b3e271547708db86b83d83c3bdac3bca9494433 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 6 Oct 2024 09:18:37 +0800 +Subject: crypto: api - Fix liveliness check in crypto_alg_tested + +From: Herbert Xu + +[ 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 +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/crypto-marvell-cesa-disable-hash-algorithms.patch b/queue-6.1/crypto-marvell-cesa-disable-hash-algorithms.patch new file mode 100644 index 00000000000..caf21d6e505 --- /dev/null +++ b/queue-6.1/crypto-marvell-cesa-disable-hash-algorithms.patch @@ -0,0 +1,81 @@ +From 2d50aa477bada01aeb68b798932970f156461475 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 9 Oct 2024 16:38:48 +0800 +Subject: crypto: marvell/cesa - Disable hash algorithms + +From: Herbert Xu + +[ 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 +Signed-off-by: Herbert Xu +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/drm-vmwgfx-limit-display-layout-ioctl-array-size-to-.patch b/queue-6.1/drm-vmwgfx-limit-display-layout-ioctl-array-size-to-.patch new file mode 100644 index 00000000000..2fc28905f83 --- /dev/null +++ b/queue-6.1/drm-vmwgfx-limit-display-layout-ioctl-array-size-to-.patch @@ -0,0 +1,87 @@ +From e87b77e605e2449c6d8afb620a2e078616024f92 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +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 + +[ 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 +Reviewed-by: Zack Rusin +Reviewed-by: Martin Krastev +Signed-off-by: Zack Rusin +Link: https://patchwork.freedesktop.org/patch/msgid/20240808200634.1074083-1-ian.forbes@broadcom.com +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/hid-multitouch-add-quirk-for-honor-magicbook-art-14-.patch b/queue-6.1/hid-multitouch-add-quirk-for-honor-magicbook-art-14-.patch new file mode 100644 index 00000000000..4d26714119a --- /dev/null +++ b/queue-6.1/hid-multitouch-add-quirk-for-honor-magicbook-art-14-.patch @@ -0,0 +1,47 @@ +From 738a870b2dd1d392013a016e1db316435af00f07 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 7 Oct 2024 12:08:03 +0800 +Subject: HID: multitouch: Add quirk for HONOR MagicBook Art 14 touchpad + +From: WangYuli + +[ 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 +Signed-off-by: WangYuli +Reviewed-by: Benjamin Tissoires +Signed-off-by: Jiri Kosina +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/hid-multitouch-add-support-for-b2402fva-track-point.patch b/queue-6.1/hid-multitouch-add-support-for-b2402fva-track-point.patch new file mode 100644 index 00000000000..9feee03e758 --- /dev/null +++ b/queue-6.1/hid-multitouch-add-support-for-b2402fva-track-point.patch @@ -0,0 +1,44 @@ +From e48678a4f99d0312567b89f2b79c5f89decf7bc6 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Sun, 6 Oct 2024 10:12:23 +0200 +Subject: HID: multitouch: Add support for B2402FVA track point + +From: Stefan Blum + +[ 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 +Signed-off-by: Jiri Kosina +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/irqchip-ocelot-fix-trigger-register-address.patch b/queue-6.1/irqchip-ocelot-fix-trigger-register-address.patch new file mode 100644 index 00000000000..a8322cd68c6 --- /dev/null +++ b/queue-6.1/irqchip-ocelot-fix-trigger-register-address.patch @@ -0,0 +1,56 @@ +From a4d696a161336691f882ebfab1d12d11304c5a1e Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 25 Sep 2024 21:44:15 +0300 +Subject: irqchip/ocelot: Fix trigger register address + +From: Sergey Matsievskiy + +[ 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 +Signed-off-by: Thomas Gleixner +Link: https://lore.kernel.org/all/20240925184416.54204-2-matsievskiysv@gmail.com +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/kasan-disable-software-tag-based-kasan-with-gcc.patch b/queue-6.1/kasan-disable-software-tag-based-kasan-with-gcc.patch new file mode 100644 index 00000000000..0de40113a01 --- /dev/null +++ b/queue-6.1/kasan-disable-software-tag-based-kasan-with-gcc.patch @@ -0,0 +1,81 @@ +From 5f1f50fcbb793495ab320bdb4beb603bf965c2ce Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 14 Oct 2024 17:11:00 +0100 +Subject: kasan: Disable Software Tag-Based KASAN with GCC + +From: Will Deacon + +[ 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 +Suggested-by: Mark Rutland +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 +Acked-by: Mark Rutland +Link: https://lore.kernel.org/r/20241014161100.18034-1-will@kernel.org +Signed-off-by: Will Deacon +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/nvme-disable-cc.crime-nvme_cc_crime.patch b/queue-6.1/nvme-disable-cc.crime-nvme_cc_crime.patch new file mode 100644 index 00000000000..7e69eb29e9c --- /dev/null +++ b/queue-6.1/nvme-disable-cc.crime-nvme_cc_crime.patch @@ -0,0 +1,57 @@ +From 8ede27b0bbb3f9b7a87991ae4395601c2f2ee2e0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Mon, 7 Oct 2024 14:33:24 -0500 +Subject: nvme: disable CC.CRIME (NVME_CC_CRIME) + +From: Greg Joyce + +[ 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 +Reviewed-by: Nilay Shroff +Tested-by: Nilay Shroff +Signed-off-by: Keith Busch +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/nvme-make-keep-alive-synchronous-operation.patch b/queue-6.1/nvme-make-keep-alive-synchronous-operation.patch new file mode 100644 index 00000000000..fcd85a6e3b3 --- /dev/null +++ b/queue-6.1/nvme-make-keep-alive-synchronous-operation.patch @@ -0,0 +1,122 @@ +From 94e0d57b1c74287318fc37cdae24f943e4da088f Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 16 Oct 2024 08:33:15 +0530 +Subject: nvme: make keep-alive synchronous operation + +From: Nilay Shroff + +[ 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 +Signed-off-by: Nilay Shroff +Signed-off-by: Keith Busch +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/nvme-multipath-defer-partition-scanning.patch b/queue-6.1/nvme-multipath-defer-partition-scanning.patch new file mode 100644 index 00000000000..d84f6f7a978 --- /dev/null +++ b/queue-6.1/nvme-multipath-defer-partition-scanning.patch @@ -0,0 +1,118 @@ +From 2f209562d84e21d38000dff355bba6c7477b4fd3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Tue, 15 Oct 2024 07:30:17 -0700 +Subject: nvme-multipath: defer partition scanning + +From: Keith Busch + +[ 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 +Reviewed-by: Christoph Hellwig +Signed-off-by: Keith Busch +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/nvme-tcp-avoid-race-between-queue_lock-lock-and-dest.patch b/queue-6.1/nvme-tcp-avoid-race-between-queue_lock-lock-and-dest.patch new file mode 100644 index 00000000000..9e4941d42c3 --- /dev/null +++ b/queue-6.1/nvme-tcp-avoid-race-between-queue_lock-lock-and-dest.patch @@ -0,0 +1,140 @@ +From 526d1eee75b4e11d986289ca29cc9543c79d72a0 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Wed, 2 Oct 2024 13:51:41 +0900 +Subject: nvme: tcp: avoid race between queue_lock lock and destroy + +From: Hannes Reinecke + +[ 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: + + ? __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 + + +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 +Signed-off-by: Shin'ichiro Kawasaki +Signed-off-by: Keith Busch +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/powerpc-powernv-free-name-on-error-in-opal_event_ini.patch b/queue-6.1/powerpc-powernv-free-name-on-error-in-opal_event_ini.patch new file mode 100644 index 00000000000..f75d70465e0 --- /dev/null +++ b/queue-6.1/powerpc-powernv-free-name-on-error-in-opal_event_ini.patch @@ -0,0 +1,39 @@ +From 95a0ed1626069b822c4ee8678b09acff7f994af3 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Fri, 20 Sep 2024 19:35:20 +1000 +Subject: powerpc/powernv: Free name on error in opal_event_init() + +From: Michael Ellerman + +[ 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 +Link: https://patch.msgid.link/20240920093520.67997-1-mpe@ellerman.id.au +Signed-off-by: Sasha Levin +--- + 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 + diff --git a/queue-6.1/series b/queue-6.1/series index f02660b9864..12b76205aa4 100644 --- a/queue-6.1/series +++ b/queue-6.1/series @@ -3,3 +3,19 @@ revert-bluetooth-hci_sync-fix-overwriting-request-callback.patch 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 diff --git a/queue-6.1/sound-make-config_snd-depend-on-indirect_iomem-inste.patch b/queue-6.1/sound-make-config_snd-depend-on-indirect_iomem-inste.patch new file mode 100644 index 00000000000..108a2b5baee --- /dev/null +++ b/queue-6.1/sound-make-config_snd-depend-on-indirect_iomem-inste.patch @@ -0,0 +1,40 @@ +From 2bd4adcdf43d92cb19392cd617b22767b540a436 Mon Sep 17 00:00:00 2001 +From: Sasha Levin +Date: Thu, 10 Oct 2024 14:46:01 +0200 +Subject: sound: Make CONFIG_SND depend on INDIRECT_IOMEM instead of UML + +From: Julian Vetter + +[ 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 +Signed-off-by: Julian Vetter +Link: https://patch.msgid.link/20241010124601.700528-1-jvetter@kalrayinc.com +Signed-off-by: Takashi Iwai +Signed-off-by: Sasha Levin +--- + 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 +