From f1a6e3e1fdb6b911fe9827c9753bf0fb5fe5b580 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Tue, 3 Dec 2024 11:07:40 +0100 Subject: [PATCH] 6.12-stable patches added patches: block-prevent-potential-deadlock-in-blk_revalidate_disk_zones.patch dt-bindings-serial-rs485-fix-rs485-rts-delay-property.patch iio-gts-fix-uninitialized-symbol-ret.patch irqchip-irq-mvebu-sei-move-misplaced-select-callback-to-sei-cp-domain.patch jffs2-prevent-rtime-decompress-memory-corruption.patch mtd-ubi-fix-unreleased-fwnode_handle-in-find_volume_fwnode.patch revert-block-bfq-merge-bfq_release_process_ref-into-bfq_put_cooperator.patch serial-8250-omap-move-pm_runtime_get_sync.patch serial-8250_fintek-add-support-for-f81216e.patch serial-amba-pl011-fix-build-regression.patch serial-amba-pl011-fix-rx-stall-when-dma-is-used.patch sh-cpuinfo-fix-a-warning-for-config_cpumask_offstack.patch ubi-wl-put-source-peb-into-correct-list-if-trying-locking-leb-failed.patch um-net-do-not-use-drvdata-in-release.patch um-ubd-do-not-use-drvdata-in-release.patch um-vector-do-not-use-drvdata-in-release.patch x86-cpu-amd-terminate-the-erratum_1386_microcode-array.patch --- ...eadlock-in-blk_revalidate_disk_zones.patch | 152 ++++++++++++++ ...l-rs485-fix-rs485-rts-delay-property.patch | 51 +++++ ...iio-gts-fix-uninitialized-symbol-ret.patch | 36 ++++ ...ced-select-callback-to-sei-cp-domain.patch | 56 +++++ ...t-rtime-decompress-memory-corruption.patch | 34 +++ ...-fwnode_handle-in-find_volume_fwnode.patch | 39 ++++ ..._process_ref-into-bfq_put_cooperator.patch | 196 ++++++++++++++++++ ...l-8250-omap-move-pm_runtime_get_sync.patch | 48 +++++ ...-8250_fintek-add-support-for-f81216e.patch | 92 ++++++++ ...rial-amba-pl011-fix-build-regression.patch | 52 +++++ ...-pl011-fix-rx-stall-when-dma-is-used.patch | 44 ++++ queue-6.12/series | 17 ++ ...-warning-for-config_cpumask_offstack.patch | 64 ++++++ ...ct-list-if-trying-locking-leb-failed.patch | 61 ++++++ ...um-net-do-not-use-drvdata-in-release.patch | 74 +++++++ ...um-ubd-do-not-use-drvdata-in-release.patch | 78 +++++++ ...vector-do-not-use-drvdata-in-release.patch | 75 +++++++ ...ate-the-erratum_1386_microcode-array.patch | 35 ++++ 18 files changed, 1204 insertions(+) create mode 100644 queue-6.12/block-prevent-potential-deadlock-in-blk_revalidate_disk_zones.patch create mode 100644 queue-6.12/dt-bindings-serial-rs485-fix-rs485-rts-delay-property.patch create mode 100644 queue-6.12/iio-gts-fix-uninitialized-symbol-ret.patch create mode 100644 queue-6.12/irqchip-irq-mvebu-sei-move-misplaced-select-callback-to-sei-cp-domain.patch create mode 100644 queue-6.12/jffs2-prevent-rtime-decompress-memory-corruption.patch create mode 100644 queue-6.12/mtd-ubi-fix-unreleased-fwnode_handle-in-find_volume_fwnode.patch create mode 100644 queue-6.12/revert-block-bfq-merge-bfq_release_process_ref-into-bfq_put_cooperator.patch create mode 100644 queue-6.12/serial-8250-omap-move-pm_runtime_get_sync.patch create mode 100644 queue-6.12/serial-8250_fintek-add-support-for-f81216e.patch create mode 100644 queue-6.12/serial-amba-pl011-fix-build-regression.patch create mode 100644 queue-6.12/serial-amba-pl011-fix-rx-stall-when-dma-is-used.patch create mode 100644 queue-6.12/sh-cpuinfo-fix-a-warning-for-config_cpumask_offstack.patch create mode 100644 queue-6.12/ubi-wl-put-source-peb-into-correct-list-if-trying-locking-leb-failed.patch create mode 100644 queue-6.12/um-net-do-not-use-drvdata-in-release.patch create mode 100644 queue-6.12/um-ubd-do-not-use-drvdata-in-release.patch create mode 100644 queue-6.12/um-vector-do-not-use-drvdata-in-release.patch create mode 100644 queue-6.12/x86-cpu-amd-terminate-the-erratum_1386_microcode-array.patch diff --git a/queue-6.12/block-prevent-potential-deadlock-in-blk_revalidate_disk_zones.patch b/queue-6.12/block-prevent-potential-deadlock-in-blk_revalidate_disk_zones.patch new file mode 100644 index 00000000000..975d8144edd --- /dev/null +++ b/queue-6.12/block-prevent-potential-deadlock-in-blk_revalidate_disk_zones.patch @@ -0,0 +1,152 @@ +From 0b83c86b444ab467134b0e618f45ad2216a4973c Mon Sep 17 00:00:00 2001 +From: Damien Le Moal +Date: Tue, 26 Nov 2024 19:47:05 +0900 +Subject: block: Prevent potential deadlock in blk_revalidate_disk_zones() + +From: Damien Le Moal + +commit 0b83c86b444ab467134b0e618f45ad2216a4973c upstream. + +The function blk_revalidate_disk_zones() calls the function +disk_update_zone_resources() after freezing the device queue. In turn, +disk_update_zone_resources() calls queue_limits_start_update() which +takes a queue limits mutex lock, resulting in the ordering: +q->q_usage_counter check -> q->limits_lock. However, the usual ordering +is to always take a queue limit lock before freezing the queue to commit +the limits updates, e.g., the code pattern: + +lim = queue_limits_start_update(q); +... +blk_mq_freeze_queue(q); +ret = queue_limits_commit_update(q, &lim); +blk_mq_unfreeze_queue(q); + +Thus, blk_revalidate_disk_zones() introduces a potential circular +locking dependency deadlock that lockdep sometimes catches with the +splat: + +[ 51.934109] ====================================================== +[ 51.935916] WARNING: possible circular locking dependency detected +[ 51.937561] 6.12.0+ #2107 Not tainted +[ 51.938648] ------------------------------------------------------ +[ 51.940351] kworker/u16:4/157 is trying to acquire lock: +[ 51.941805] ffff9fff0aa0bea8 (&q->limits_lock){+.+.}-{4:4}, at: disk_update_zone_resources+0x86/0x170 +[ 51.944314] + but task is already holding lock: +[ 51.945688] ffff9fff0aa0b890 (&q->q_usage_counter(queue)#3){++++}-{0:0}, at: blk_revalidate_disk_zones+0x15f/0x340 +[ 51.948527] + which lock already depends on the new lock. + +[ 51.951296] + the existing dependency chain (in reverse order) is: +[ 51.953708] + -> #1 (&q->q_usage_counter(queue)#3){++++}-{0:0}: +[ 51.956131] blk_queue_enter+0x1c9/0x1e0 +[ 51.957290] blk_mq_alloc_request+0x187/0x2a0 +[ 51.958365] scsi_execute_cmd+0x78/0x490 [scsi_mod] +[ 51.959514] read_capacity_16+0x111/0x410 [sd_mod] +[ 51.960693] sd_revalidate_disk.isra.0+0x872/0x3240 [sd_mod] +[ 51.962004] sd_probe+0x2d7/0x520 [sd_mod] +[ 51.962993] really_probe+0xd5/0x330 +[ 51.963898] __driver_probe_device+0x78/0x110 +[ 51.964925] driver_probe_device+0x1f/0xa0 +[ 51.965916] __driver_attach_async_helper+0x60/0xe0 +[ 51.967017] async_run_entry_fn+0x2e/0x140 +[ 51.968004] process_one_work+0x21f/0x5a0 +[ 51.968987] worker_thread+0x1dc/0x3c0 +[ 51.969868] kthread+0xe0/0x110 +[ 51.970377] ret_from_fork+0x31/0x50 +[ 51.970983] ret_from_fork_asm+0x11/0x20 +[ 51.971587] + -> #0 (&q->limits_lock){+.+.}-{4:4}: +[ 51.972479] __lock_acquire+0x1337/0x2130 +[ 51.973133] lock_acquire+0xc5/0x2d0 +[ 51.973691] __mutex_lock+0xda/0xcf0 +[ 51.974300] disk_update_zone_resources+0x86/0x170 +[ 51.975032] blk_revalidate_disk_zones+0x16c/0x340 +[ 51.975740] sd_zbc_revalidate_zones+0x73/0x160 [sd_mod] +[ 51.976524] sd_revalidate_disk.isra.0+0x465/0x3240 [sd_mod] +[ 51.977824] sd_probe+0x2d7/0x520 [sd_mod] +[ 51.978917] really_probe+0xd5/0x330 +[ 51.979915] __driver_probe_device+0x78/0x110 +[ 51.981047] driver_probe_device+0x1f/0xa0 +[ 51.982143] __driver_attach_async_helper+0x60/0xe0 +[ 51.983282] async_run_entry_fn+0x2e/0x140 +[ 51.984319] process_one_work+0x21f/0x5a0 +[ 51.985873] worker_thread+0x1dc/0x3c0 +[ 51.987289] kthread+0xe0/0x110 +[ 51.988546] ret_from_fork+0x31/0x50 +[ 51.989926] ret_from_fork_asm+0x11/0x20 +[ 51.991376] + other info that might help us debug this: + +[ 51.994127] Possible unsafe locking scenario: + +[ 51.995651] CPU0 CPU1 +[ 51.996694] ---- ---- +[ 51.997716] lock(&q->q_usage_counter(queue)#3); +[ 51.998817] lock(&q->limits_lock); +[ 52.000043] lock(&q->q_usage_counter(queue)#3); +[ 52.001638] lock(&q->limits_lock); +[ 52.002485] + *** DEADLOCK *** + +Prevent this issue by moving the calls to blk_mq_freeze_queue() and +blk_mq_unfreeze_queue() around the call to queue_limits_commit_update() +in disk_update_zone_resources(). In case of revalidation failure, the +call to disk_free_zone_resources() in blk_revalidate_disk_zones() +is still done with the queue frozen as before. + +Fixes: 843283e96e5a ("block: Fake max open zones limit when there is no limit") +Cc: stable@vger.kernel.org +Signed-off-by: Damien Le Moal +Reviewed-by: Christoph Hellwig +Link: https://lore.kernel.org/r/20241126104705.183996-1-dlemoal@kernel.org +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + block/blk-zoned.c | 14 ++++++++++---- + 1 file changed, 10 insertions(+), 4 deletions(-) + +--- a/block/blk-zoned.c ++++ b/block/blk-zoned.c +@@ -1541,6 +1541,7 @@ static int disk_update_zone_resources(st + unsigned int nr_seq_zones, nr_conv_zones = 0; + unsigned int pool_size; + struct queue_limits lim; ++ int ret; + + disk->nr_zones = args->nr_zones; + disk->zone_capacity = args->zone_capacity; +@@ -1593,7 +1594,11 @@ static int disk_update_zone_resources(st + } + + commit: +- return queue_limits_commit_update(q, &lim); ++ blk_mq_freeze_queue(q); ++ ret = queue_limits_commit_update(q, &lim); ++ blk_mq_unfreeze_queue(q); ++ ++ return ret; + } + + static int blk_revalidate_conv_zone(struct blk_zone *zone, unsigned int idx, +@@ -1814,14 +1819,15 @@ int blk_revalidate_disk_zones(struct gen + * Set the new disk zone parameters only once the queue is frozen and + * all I/Os are completed. + */ +- blk_mq_freeze_queue(q); + if (ret > 0) + ret = disk_update_zone_resources(disk, &args); + else + pr_warn("%s: failed to revalidate zones\n", disk->disk_name); +- if (ret) ++ if (ret) { ++ blk_mq_freeze_queue(q); + disk_free_zone_resources(disk); +- blk_mq_unfreeze_queue(q); ++ blk_mq_unfreeze_queue(q); ++ } + + kfree(args.conv_zones_bitmap); + diff --git a/queue-6.12/dt-bindings-serial-rs485-fix-rs485-rts-delay-property.patch b/queue-6.12/dt-bindings-serial-rs485-fix-rs485-rts-delay-property.patch new file mode 100644 index 00000000000..cfd2b0ed4ba --- /dev/null +++ b/queue-6.12/dt-bindings-serial-rs485-fix-rs485-rts-delay-property.patch @@ -0,0 +1,51 @@ +From 12b3642b6c242061d3ba84e6e3050c3141ded14c Mon Sep 17 00:00:00 2001 +From: Michal Simek +Date: Mon, 16 Sep 2024 11:53:06 +0200 +Subject: dt-bindings: serial: rs485: Fix rs485-rts-delay property + +From: Michal Simek + +commit 12b3642b6c242061d3ba84e6e3050c3141ded14c upstream. + +Code expects array only with 2 items which should be checked. +But also item checking is not working as it should likely because of +incorrect items description. + +Fixes: d50f974c4f7f ("dt-bindings: serial: Convert rs485 bindings to json-schema") +Signed-off-by: Michal Simek +Cc: stable@vger.kernel.org +Reviewed-by: Krzysztof Kozlowski +Link: https://lore.kernel.org/r/820c639b9e22fe037730ed44d1b044cdb6d28b75.1726480384.git.michal.simek@amd.com +Signed-off-by: Greg Kroah-Hartman +--- + Documentation/devicetree/bindings/serial/rs485.yaml | 19 +++++++++---------- + 1 file changed, 9 insertions(+), 10 deletions(-) + +--- a/Documentation/devicetree/bindings/serial/rs485.yaml ++++ b/Documentation/devicetree/bindings/serial/rs485.yaml +@@ -18,16 +18,15 @@ properties: + description: prop-encoded-array + $ref: /schemas/types.yaml#/definitions/uint32-array + items: +- items: +- - description: Delay between rts signal and beginning of data sent in +- milliseconds. It corresponds to the delay before sending data. +- default: 0 +- maximum: 100 +- - description: Delay between end of data sent and rts signal in milliseconds. +- It corresponds to the delay after sending data and actual release +- of the line. +- default: 0 +- maximum: 100 ++ - description: Delay between rts signal and beginning of data sent in ++ milliseconds. It corresponds to the delay before sending data. ++ default: 0 ++ maximum: 100 ++ - description: Delay between end of data sent and rts signal in milliseconds. ++ It corresponds to the delay after sending data and actual release ++ of the line. ++ default: 0 ++ maximum: 100 + + rs485-rts-active-high: + description: drive RTS high when sending (this is the default). diff --git a/queue-6.12/iio-gts-fix-uninitialized-symbol-ret.patch b/queue-6.12/iio-gts-fix-uninitialized-symbol-ret.patch new file mode 100644 index 00000000000..0ccf2964ec5 --- /dev/null +++ b/queue-6.12/iio-gts-fix-uninitialized-symbol-ret.patch @@ -0,0 +1,36 @@ +From e2fb2f89faf87b681038475d093214f4cbe12ebb Mon Sep 17 00:00:00 2001 +From: Zicheng Qu +Date: Thu, 31 Oct 2024 01:45:05 +0000 +Subject: iio: gts: Fix uninitialized symbol 'ret' + +From: Zicheng Qu + +commit e2fb2f89faf87b681038475d093214f4cbe12ebb upstream. + +Initialize the variable ret at the time of declaration to prevent it from +being returned without a defined value. Fixes smatch warning: +drivers/iio/industrialio-gts-helper.c:256 gain_to_scaletables() error: +uninitialized symbol 'ret'. + +Cc: stable@vger.kernel.org # v6.6+ +Fixes: 38416c28e168 ("iio: light: Add gain-time-scale helpers") +Signed-off-by: Zicheng Qu +Reviewed-by: Matti Vaittinen +Link: https://patch.msgid.link/20241031014505.2313035-1-quzicheng@huawei.com +Signed-off-by: Jonathan Cameron +Signed-off-by: Greg Kroah-Hartman +--- + drivers/iio/industrialio-gts-helper.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/iio/industrialio-gts-helper.c ++++ b/drivers/iio/industrialio-gts-helper.c +@@ -167,7 +167,7 @@ static int iio_gts_gain_cmp(const void * + + static int gain_to_scaletables(struct iio_gts *gts, int **gains, int **scales) + { +- int ret, i, j, new_idx, time_idx; ++ int i, j, new_idx, time_idx, ret = 0; + int *all_gains; + size_t gain_bytes; + diff --git a/queue-6.12/irqchip-irq-mvebu-sei-move-misplaced-select-callback-to-sei-cp-domain.patch b/queue-6.12/irqchip-irq-mvebu-sei-move-misplaced-select-callback-to-sei-cp-domain.patch new file mode 100644 index 00000000000..73811654c02 --- /dev/null +++ b/queue-6.12/irqchip-irq-mvebu-sei-move-misplaced-select-callback-to-sei-cp-domain.patch @@ -0,0 +1,56 @@ +From 12aaf67584cf19dc84615b7aba272fe642c35b8b Mon Sep 17 00:00:00 2001 +From: "Russell King (Oracle)" +Date: Thu, 21 Nov 2024 12:48:25 +0000 +Subject: irqchip/irq-mvebu-sei: Move misplaced select() callback to SEI CP domain + +From: Russell King (Oracle) + +commit 12aaf67584cf19dc84615b7aba272fe642c35b8b upstream. + +Commit fbdf14e90ce4 ("irqchip/irq-mvebu-sei: Switch to MSI parent") +introduced in v6.11-rc1 broke Mavell Armada platforms (and possibly others) +by incorrectly switching irq-mvebu-sei to MSI parent. + +In the above commit, msi_parent_ops is set for the sei->cp_domain, but +rather than adding a .select method to mvebu_sei_cp_domain_ops (which is +associated with sei->cp_domain), it was added to mvebu_sei_domain_ops which +is associated with sei->sei_domain, which doesn't have any +msi_parent_ops. This makes the call to msi_lib_irq_domain_select() always +fail. + +This bug manifests itself with the following kernel messages on Armada 8040 +based systems: + + platform f21e0000.interrupt-controller:interrupt-controller@50: deferred probe pending: (reason unknown) + platform f41e0000.interrupt-controller:interrupt-controller@50: deferred probe pending: (reason unknown) + +Move the select callback to mvebu_sei_cp_domain_ops to cure it. + +Fixes: fbdf14e90ce4 ("irqchip/irq-mvebu-sei: Switch to MSI parent") +Signed-off-by: Russell King (Oracle) +Signed-off-by: Thomas Gleixner +Cc: stable@vger.kernel.org +Link: https://lore.kernel.org/all/E1tE6bh-004CmX-QU@rmk-PC.armlinux.org.uk +Signed-off-by: Greg Kroah-Hartman +--- + drivers/irqchip/irq-mvebu-sei.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/drivers/irqchip/irq-mvebu-sei.c ++++ b/drivers/irqchip/irq-mvebu-sei.c +@@ -192,7 +192,6 @@ static void mvebu_sei_domain_free(struct + } + + static const struct irq_domain_ops mvebu_sei_domain_ops = { +- .select = msi_lib_irq_domain_select, + .alloc = mvebu_sei_domain_alloc, + .free = mvebu_sei_domain_free, + }; +@@ -306,6 +305,7 @@ static void mvebu_sei_cp_domain_free(str + } + + static const struct irq_domain_ops mvebu_sei_cp_domain_ops = { ++ .select = msi_lib_irq_domain_select, + .alloc = mvebu_sei_cp_domain_alloc, + .free = mvebu_sei_cp_domain_free, + }; diff --git a/queue-6.12/jffs2-prevent-rtime-decompress-memory-corruption.patch b/queue-6.12/jffs2-prevent-rtime-decompress-memory-corruption.patch new file mode 100644 index 00000000000..078df2a6d66 --- /dev/null +++ b/queue-6.12/jffs2-prevent-rtime-decompress-memory-corruption.patch @@ -0,0 +1,34 @@ +From fe051552f5078fa02d593847529a3884305a6ffe Mon Sep 17 00:00:00 2001 +From: Kinsey Moore +Date: Tue, 23 Jul 2024 15:58:05 -0500 +Subject: jffs2: Prevent rtime decompress memory corruption + +From: Kinsey Moore + +commit fe051552f5078fa02d593847529a3884305a6ffe upstream. + +The rtime decompression routine does not fully check bounds during the +entirety of the decompression pass and can corrupt memory outside the +decompression buffer if the compressed data is corrupted. This adds the +required check to prevent this failure mode. + +Cc: stable@vger.kernel.org +Signed-off-by: Kinsey Moore +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman +--- + fs/jffs2/compr_rtime.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/fs/jffs2/compr_rtime.c ++++ b/fs/jffs2/compr_rtime.c +@@ -95,6 +95,9 @@ static int jffs2_rtime_decompress(unsign + + positions[value]=outpos; + if (repeat) { ++ if ((outpos + repeat) >= destlen) { ++ return 1; ++ } + if (backoffs + repeat >= outpos) { + while(repeat) { + cpage_out[outpos++] = cpage_out[backoffs++]; diff --git a/queue-6.12/mtd-ubi-fix-unreleased-fwnode_handle-in-find_volume_fwnode.patch b/queue-6.12/mtd-ubi-fix-unreleased-fwnode_handle-in-find_volume_fwnode.patch new file mode 100644 index 00000000000..002c99dcb57 --- /dev/null +++ b/queue-6.12/mtd-ubi-fix-unreleased-fwnode_handle-in-find_volume_fwnode.patch @@ -0,0 +1,39 @@ +From 07593293ffabba14125c8998525adde5a832bfa3 Mon Sep 17 00:00:00 2001 +From: Javier Carrasco +Date: Sat, 19 Oct 2024 22:27:03 +0200 +Subject: mtd: ubi: fix unreleased fwnode_handle in find_volume_fwnode() + +From: Javier Carrasco + +commit 07593293ffabba14125c8998525adde5a832bfa3 upstream. + +The 'fw_vols' fwnode_handle initialized via +device_get_named_child_node() requires explicit calls to +fwnode_handle_put() when the variable is no longer required. + +Add the missing calls to fwnode_handle_put() before the function +returns. + +Cc: stable@vger.kernel.org +Fixes: 51932f9fc487 ("mtd: ubi: populate ubi volume fwnode") +Signed-off-by: Javier Carrasco +Reviewed-by: Zhihao Cheng +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/ubi/vmt.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/mtd/ubi/vmt.c ++++ b/drivers/mtd/ubi/vmt.c +@@ -143,8 +143,10 @@ static struct fwnode_handle *find_volume + vol->vol_id != volid) + continue; + ++ fwnode_handle_put(fw_vols); + return fw_vol; + } ++ fwnode_handle_put(fw_vols); + + return NULL; + } diff --git a/queue-6.12/revert-block-bfq-merge-bfq_release_process_ref-into-bfq_put_cooperator.patch b/queue-6.12/revert-block-bfq-merge-bfq_release_process_ref-into-bfq_put_cooperator.patch new file mode 100644 index 00000000000..689711d0183 --- /dev/null +++ b/queue-6.12/revert-block-bfq-merge-bfq_release_process_ref-into-bfq_put_cooperator.patch @@ -0,0 +1,196 @@ +From cf5a60d971c7b59efb89927919404be655a9e35a Mon Sep 17 00:00:00 2001 +From: Zach Wade +Date: Tue, 19 Nov 2024 23:34:10 +0800 +Subject: Revert "block, bfq: merge bfq_release_process_ref() into bfq_put_cooperator()" + +From: Zach Wade + +commit cf5a60d971c7b59efb89927919404be655a9e35a upstream. + +This reverts commit bc3b1e9e7c50e1de0f573eea3871db61dd4787de. + +The bic is associated with sync_bfqq, and bfq_release_process_ref cannot +be put into bfq_put_cooperator. + +kasan report: +[ 400.347277] ================================================================== +[ 400.347287] BUG: KASAN: slab-use-after-free in bic_set_bfqq+0x200/0x230 +[ 400.347420] Read of size 8 at addr ffff88881cab7d60 by task dockerd/5800 +[ 400.347430] +[ 400.347436] CPU: 24 UID: 0 PID: 5800 Comm: dockerd Kdump: loaded Tainted: G E 6.12.0 #32 +[ 400.347450] Tainted: [E]=UNSIGNED_MODULE +[ 400.347454] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 +[ 400.347460] Call Trace: +[ 400.347464] +[ 400.347468] dump_stack_lvl+0x5d/0x80 +[ 400.347490] print_report+0x174/0x505 +[ 400.347521] kasan_report+0xe0/0x160 +[ 400.347541] bic_set_bfqq+0x200/0x230 +[ 400.347549] bfq_bic_update_cgroup+0x419/0x740 +[ 400.347560] bfq_bio_merge+0x133/0x320 +[ 400.347584] blk_mq_submit_bio+0x1761/0x1e20 +[ 400.347625] __submit_bio+0x28b/0x7b0 +[ 400.347664] submit_bio_noacct_nocheck+0x6b2/0xd30 +[ 400.347690] iomap_readahead+0x50c/0x680 +[ 400.347731] read_pages+0x17f/0x9c0 +[ 400.347785] page_cache_ra_unbounded+0x366/0x4a0 +[ 400.347795] filemap_fault+0x83d/0x2340 +[ 400.347819] __xfs_filemap_fault+0x11a/0x7d0 [xfs] +[ 400.349256] __do_fault+0xf1/0x610 +[ 400.349270] do_fault+0x977/0x11a0 +[ 400.349281] __handle_mm_fault+0x5d1/0x850 +[ 400.349314] handle_mm_fault+0x1f8/0x560 +[ 400.349324] do_user_addr_fault+0x324/0x970 +[ 400.349337] exc_page_fault+0x76/0xf0 +[ 400.349350] asm_exc_page_fault+0x26/0x30 +[ 400.349360] RIP: 0033:0x55a480d77375 +[ 400.349384] Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 49 3b 66 10 0f 86 ae 02 00 00 55 48 89 e5 48 83 ec 58 48 8b 10 <83> 7a 10 00 0f 84 27 02 00 00 44 0f b6 42 28 44 0f b6 4a 29 41 80 +[ 400.349392] RSP: 002b:00007f18c37fd8b8 EFLAGS: 00010216 +[ 400.349401] RAX: 00007f18c37fd9d0 RBX: 0000000000000000 RCX: 0000000000000000 +[ 400.349407] RDX: 000055a484407d38 RSI: 000000c000e8b0c0 RDI: 0000000000000000 +[ 400.349412] RBP: 00007f18c37fd910 R08: 000055a484017f60 R09: 000055a484066f80 +[ 400.349417] R10: 0000000000194000 R11: 0000000000000005 R12: 0000000000000008 +[ 400.349422] R13: 0000000000000000 R14: 000000c000476a80 R15: 0000000000000000 +[ 400.349430] +[ 400.349452] +[ 400.349454] Allocated by task 5800: +[ 400.349459] kasan_save_stack+0x30/0x50 +[ 400.349469] kasan_save_track+0x14/0x30 +[ 400.349475] __kasan_slab_alloc+0x89/0x90 +[ 400.349482] kmem_cache_alloc_node_noprof+0xdc/0x2a0 +[ 400.349492] bfq_get_queue+0x1ef/0x1100 +[ 400.349502] __bfq_get_bfqq_handle_split+0x11a/0x510 +[ 400.349511] bfq_insert_requests+0xf55/0x9030 +[ 400.349519] blk_mq_flush_plug_list+0x446/0x14c0 +[ 400.349527] __blk_flush_plug+0x27c/0x4e0 +[ 400.349534] blk_finish_plug+0x52/0xa0 +[ 400.349540] _xfs_buf_ioapply+0x739/0xc30 [xfs] +[ 400.350246] __xfs_buf_submit+0x1b2/0x640 [xfs] +[ 400.350967] xfs_buf_read_map+0x306/0xa20 [xfs] +[ 400.351672] xfs_trans_read_buf_map+0x285/0x7d0 [xfs] +[ 400.352386] xfs_imap_to_bp+0x107/0x270 [xfs] +[ 400.353077] xfs_iget+0x70d/0x1eb0 [xfs] +[ 400.353786] xfs_lookup+0x2ca/0x3a0 [xfs] +[ 400.354506] xfs_vn_lookup+0x14e/0x1a0 [xfs] +[ 400.355197] __lookup_slow+0x19c/0x340 +[ 400.355204] lookup_one_unlocked+0xfc/0x120 +[ 400.355211] ovl_lookup_single+0x1b3/0xcf0 [overlay] +[ 400.355255] ovl_lookup_layer+0x316/0x490 [overlay] +[ 400.355295] ovl_lookup+0x844/0x1fd0 [overlay] +[ 400.355351] lookup_one_qstr_excl+0xef/0x150 +[ 400.355357] do_unlinkat+0x22a/0x620 +[ 400.355366] __x64_sys_unlinkat+0x109/0x1e0 +[ 400.355375] do_syscall_64+0x82/0x160 +[ 400.355384] entry_SYSCALL_64_after_hwframe+0x76/0x7e +[ 400.355393] +[ 400.355395] Freed by task 5800: +[ 400.355400] kasan_save_stack+0x30/0x50 +[ 400.355407] kasan_save_track+0x14/0x30 +[ 400.355413] kasan_save_free_info+0x3b/0x70 +[ 400.355422] __kasan_slab_free+0x4f/0x70 +[ 400.355429] kmem_cache_free+0x176/0x520 +[ 400.355438] bfq_put_queue+0x67e/0x980 +[ 400.355447] bfq_bic_update_cgroup+0x407/0x740 +[ 400.355454] bfq_bio_merge+0x133/0x320 +[ 400.355460] blk_mq_submit_bio+0x1761/0x1e20 +[ 400.355467] __submit_bio+0x28b/0x7b0 +[ 400.355473] submit_bio_noacct_nocheck+0x6b2/0xd30 +[ 400.355480] iomap_readahead+0x50c/0x680 +[ 400.355490] read_pages+0x17f/0x9c0 +[ 400.355498] page_cache_ra_unbounded+0x366/0x4a0 +[ 400.355505] filemap_fault+0x83d/0x2340 +[ 400.355514] __xfs_filemap_fault+0x11a/0x7d0 [xfs] +[ 400.356204] __do_fault+0xf1/0x610 +[ 400.356213] do_fault+0x977/0x11a0 +[ 400.356221] __handle_mm_fault+0x5d1/0x850 +[ 400.356230] handle_mm_fault+0x1f8/0x560 +[ 400.356238] do_user_addr_fault+0x324/0x970 +[ 400.356248] exc_page_fault+0x76/0xf0 +[ 400.356258] asm_exc_page_fault+0x26/0x30 +[ 400.356266] +[ 400.356269] The buggy address belongs to the object at ffff88881cab7bc0 + which belongs to the cache bfq_queue of size 576 +[ 400.356276] The buggy address is located 416 bytes inside of + freed 576-byte region [ffff88881cab7bc0, ffff88881cab7e00) +[ 400.356285] +[ 400.356287] The buggy address belongs to the physical page: +[ 400.356292] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88881cab0b00 pfn:0x81cab0 +[ 400.356300] head: order:3 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 +[ 400.356323] flags: 0x50000000000040(head|node=1|zone=2) +[ 400.356331] page_type: f5(slab) +[ 400.356340] raw: 0050000000000040 ffff88880a00c280 dead000000000122 0000000000000000 +[ 400.356347] raw: ffff88881cab0b00 00000000802e0025 00000001f5000000 0000000000000000 +[ 400.356354] head: 0050000000000040 ffff88880a00c280 dead000000000122 0000000000000000 +[ 400.356359] head: ffff88881cab0b00 00000000802e0025 00000001f5000000 0000000000000000 +[ 400.356365] head: 0050000000000003 ffffea002072ac01 ffffffffffffffff 0000000000000000 +[ 400.356370] head: 0000000000000008 0000000000000000 00000000ffffffff 0000000000000000 +[ 400.356378] page dumped because: kasan: bad access detected +[ 400.356381] +[ 400.356383] Memory state around the buggy address: +[ 400.356387] ffff88881cab7c00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb +[ 400.356392] ffff88881cab7c80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb +[ 400.356397] >ffff88881cab7d00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb +[ 400.356400] ^ +[ 400.356405] ffff88881cab7d80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb +[ 400.356409] ffff88881cab7e00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc +[ 400.356413] ================================================================== + +Cc: stable@vger.kernel.org +Fixes: bc3b1e9e7c50 ("block, bfq: merge bfq_release_process_ref() into bfq_put_cooperator()") +Signed-off-by: Zach Wade +Cc: Ding Hui +Reviewed-by: Yu Kuai +Link: https://lore.kernel.org/r/20241119153410.2546-1-zachwade.k@gmail.com +Signed-off-by: Jens Axboe +Signed-off-by: Greg Kroah-Hartman +--- + block/bfq-cgroup.c | 1 + + block/bfq-iosched.c | 6 ++++-- + 2 files changed, 5 insertions(+), 2 deletions(-) + +diff --git a/block/bfq-cgroup.c b/block/bfq-cgroup.c +index e831aedb4643..9fb9f3533150 100644 +--- a/block/bfq-cgroup.c ++++ b/block/bfq-cgroup.c +@@ -736,6 +736,7 @@ static void bfq_sync_bfqq_move(struct bfq_data *bfqd, + */ + bfq_put_cooperator(sync_bfqq); + bic_set_bfqq(bic, NULL, true, act_idx); ++ bfq_release_process_ref(bfqd, sync_bfqq); + } + } + +diff --git a/block/bfq-iosched.c b/block/bfq-iosched.c +index 0747d9d0e48c..28c2bb06e859 100644 +--- a/block/bfq-iosched.c ++++ b/block/bfq-iosched.c +@@ -5434,8 +5434,6 @@ void bfq_put_cooperator(struct bfq_queue *bfqq) + bfq_put_queue(__bfqq); + __bfqq = next; + } +- +- bfq_release_process_ref(bfqq->bfqd, bfqq); + } + + static void bfq_exit_bfqq(struct bfq_data *bfqd, struct bfq_queue *bfqq) +@@ -5448,6 +5446,8 @@ static void bfq_exit_bfqq(struct bfq_data *bfqd, struct bfq_queue *bfqq) + bfq_log_bfqq(bfqd, bfqq, "exit_bfqq: %p, %d", bfqq, bfqq->ref); + + bfq_put_cooperator(bfqq); ++ ++ bfq_release_process_ref(bfqd, bfqq); + } + + static void bfq_exit_icq_bfqq(struct bfq_io_cq *bic, bool is_sync, +@@ -6734,6 +6734,8 @@ bfq_split_bfqq(struct bfq_io_cq *bic, struct bfq_queue *bfqq) + bic_set_bfqq(bic, NULL, true, bfqq->actuator_idx); + + bfq_put_cooperator(bfqq); ++ ++ bfq_release_process_ref(bfqq->bfqd, bfqq); + return NULL; + } + +-- +2.47.1 + diff --git a/queue-6.12/serial-8250-omap-move-pm_runtime_get_sync.patch b/queue-6.12/serial-8250-omap-move-pm_runtime_get_sync.patch new file mode 100644 index 00000000000..b7ce03981d3 --- /dev/null +++ b/queue-6.12/serial-8250-omap-move-pm_runtime_get_sync.patch @@ -0,0 +1,48 @@ +From bcc7ba668818dcadd2f1db66b39ed860a63ecf97 Mon Sep 17 00:00:00 2001 +From: Bin Liu +Date: Thu, 31 Oct 2024 12:23:15 -0500 +Subject: serial: 8250: omap: Move pm_runtime_get_sync + +From: Bin Liu + +commit bcc7ba668818dcadd2f1db66b39ed860a63ecf97 upstream. + +Currently in omap_8250_shutdown, the dma->rx_running flag is +set to zero in omap_8250_rx_dma_flush. Next pm_runtime_get_sync +is called, which is a runtime resume call stack which can +re-set the flag. When the call omap_8250_shutdown returns, the +flag is expected to be UN-SET, but this is not the case. This +is causing issues the next time UART is re-opened and +omap_8250_rx_dma is called. Fix by moving pm_runtime_get_sync +before the omap_8250_rx_dma_flush. + +cc: stable@vger.kernel.org +Fixes: 0e31c8d173ab ("tty: serial: 8250_omap: add custom DMA-RX callback") +Signed-off-by: Bin Liu +[Judith: Add commit message] +Signed-off-by: Judith Mendez +Reviewed-by: Kevin Hilman +Tested-by: Kevin Hilman +Link: https://lore.kernel.org/r/20241031172315.453750-1-jm@ti.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/8250/8250_omap.c | 4 ++-- + 1 file changed, 2 insertions(+), 2 deletions(-) + +--- a/drivers/tty/serial/8250/8250_omap.c ++++ b/drivers/tty/serial/8250/8250_omap.c +@@ -776,12 +776,12 @@ static void omap_8250_shutdown(struct ua + struct uart_8250_port *up = up_to_u8250p(port); + struct omap8250_priv *priv = port->private_data; + ++ pm_runtime_get_sync(port->dev); ++ + flush_work(&priv->qos_work); + if (up->dma) + omap_8250_rx_dma_flush(up); + +- pm_runtime_get_sync(port->dev); +- + serial_out(up, UART_OMAP_WER, 0); + if (priv->habit & UART_HAS_EFR2) + serial_out(up, UART_OMAP_EFR2, 0x0); diff --git a/queue-6.12/serial-8250_fintek-add-support-for-f81216e.patch b/queue-6.12/serial-8250_fintek-add-support-for-f81216e.patch new file mode 100644 index 00000000000..2dee279f01d --- /dev/null +++ b/queue-6.12/serial-8250_fintek-add-support-for-f81216e.patch @@ -0,0 +1,92 @@ +From 166105c9030a30ba08574a9998afc7b60bc72dd7 Mon Sep 17 00:00:00 2001 +From: Filip Brozovic +Date: Sun, 10 Nov 2024 12:17:00 +0100 +Subject: serial: 8250_fintek: Add support for F81216E + +From: Filip Brozovic + +commit 166105c9030a30ba08574a9998afc7b60bc72dd7 upstream. + +The F81216E is a LPC/eSPI to 4 UART Super I/O and is mostly compatible with +the F81216H, but does not support RS-485 auto-direction delays on any port. + +Signed-off-by: Filip Brozovic +Cc: stable +Link: https://lore.kernel.org/r/20241110111703.15494-1-fbrozovic@gmail.com +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/8250/8250_fintek.c | 14 +++++++++++++- + 1 file changed, 13 insertions(+), 1 deletion(-) + +--- a/drivers/tty/serial/8250/8250_fintek.c ++++ b/drivers/tty/serial/8250/8250_fintek.c +@@ -21,6 +21,7 @@ + #define CHIP_ID_F81866 0x1010 + #define CHIP_ID_F81966 0x0215 + #define CHIP_ID_F81216AD 0x1602 ++#define CHIP_ID_F81216E 0x1617 + #define CHIP_ID_F81216H 0x0501 + #define CHIP_ID_F81216 0x0802 + #define VENDOR_ID1 0x23 +@@ -158,6 +159,7 @@ static int fintek_8250_check_id(struct f + case CHIP_ID_F81866: + case CHIP_ID_F81966: + case CHIP_ID_F81216AD: ++ case CHIP_ID_F81216E: + case CHIP_ID_F81216H: + case CHIP_ID_F81216: + break; +@@ -181,6 +183,7 @@ static int fintek_8250_get_ldn_range(str + return 0; + + case CHIP_ID_F81216AD: ++ case CHIP_ID_F81216E: + case CHIP_ID_F81216H: + case CHIP_ID_F81216: + *min = F81216_LDN_LOW; +@@ -250,6 +253,7 @@ static void fintek_8250_set_irq_mode(str + break; + + case CHIP_ID_F81216AD: ++ case CHIP_ID_F81216E: + case CHIP_ID_F81216H: + case CHIP_ID_F81216: + sio_write_mask_reg(pdata, FINTEK_IRQ_MODE, IRQ_SHARE, +@@ -263,7 +267,8 @@ static void fintek_8250_set_irq_mode(str + static void fintek_8250_set_max_fifo(struct fintek_8250 *pdata) + { + switch (pdata->pid) { +- case CHIP_ID_F81216H: /* 128Bytes FIFO */ ++ case CHIP_ID_F81216E: /* 128Bytes FIFO */ ++ case CHIP_ID_F81216H: + case CHIP_ID_F81966: + case CHIP_ID_F81866: + sio_write_mask_reg(pdata, FIFO_CTRL, +@@ -297,6 +302,7 @@ static void fintek_8250_set_termios(stru + goto exit; + + switch (pdata->pid) { ++ case CHIP_ID_F81216E: + case CHIP_ID_F81216H: + reg = RS485; + break; +@@ -346,6 +352,7 @@ static void fintek_8250_set_termios_hand + struct fintek_8250 *pdata = uart->port.private_data; + + switch (pdata->pid) { ++ case CHIP_ID_F81216E: + case CHIP_ID_F81216H: + case CHIP_ID_F81966: + case CHIP_ID_F81866: +@@ -438,6 +445,11 @@ static void fintek_8250_set_rs485_handle + uart->port.rs485_supported = fintek_8250_rs485_supported; + break; + ++ case CHIP_ID_F81216E: /* F81216E does not support RS485 delays */ ++ uart->port.rs485_config = fintek_8250_rs485_config; ++ uart->port.rs485_supported = fintek_8250_rs485_supported; ++ break; ++ + default: /* No RS485 Auto direction functional */ + break; + } diff --git a/queue-6.12/serial-amba-pl011-fix-build-regression.patch b/queue-6.12/serial-amba-pl011-fix-build-regression.patch new file mode 100644 index 00000000000..fea3e4ddb49 --- /dev/null +++ b/queue-6.12/serial-amba-pl011-fix-build-regression.patch @@ -0,0 +1,52 @@ +From b5a23a60e8ab5711f4952912424347bf3864ce8d Mon Sep 17 00:00:00 2001 +From: Arnd Bergmann +Date: Fri, 15 Nov 2024 11:59:54 +0100 +Subject: serial: amba-pl011: fix build regression + +From: Arnd Bergmann + +commit b5a23a60e8ab5711f4952912424347bf3864ce8d upstream. + +When CONFIG_DMA_ENGINE is disabled, the driver now fails to build: + +drivers/tty/serial/amba-pl011.c: In function 'pl011_unthrottle_rx': +drivers/tty/serial/amba-pl011.c:1822:16: error: 'struct uart_amba_port' has no member named 'using_rx_dma' + 1822 | if (uap->using_rx_dma) { + | ^~ +drivers/tty/serial/amba-pl011.c:1823:20: error: 'struct uart_amba_port' has no member named 'dmacr' + 1823 | uap->dmacr |= UART011_RXDMAE; + | ^~ +drivers/tty/serial/amba-pl011.c:1824:32: error: 'struct uart_amba_port' has no member named 'dmacr' + 1824 | pl011_write(uap->dmacr, uap, REG_DMACR); + | ^~ + +Add the missing #ifdef check around these field accesses, matching +what other parts of this driver do. + +Fixes: 2bcacc1c87ac ("serial: amba-pl011: Fix RX stall when DMA is used") +Cc: stable +Reported-by: kernel test robot +Closes: https://lore.kernel.org/oe-kbuild-all/202411140617.nkjeHhsK-lkp@intel.com/ +Signed-off-by: Arnd Bergmann +Link: https://lore.kernel.org/r/20241115110021.744332-1-arnd@kernel.org +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/amba-pl011.c | 2 ++ + 1 file changed, 2 insertions(+) + +--- a/drivers/tty/serial/amba-pl011.c ++++ b/drivers/tty/serial/amba-pl011.c +@@ -1819,10 +1819,12 @@ static void pl011_unthrottle_rx(struct u + + pl011_write(uap->im, uap, REG_IMSC); + ++#ifdef CONFIG_DMA_ENGINE + if (uap->using_rx_dma) { + uap->dmacr |= UART011_RXDMAE; + pl011_write(uap->dmacr, uap, REG_DMACR); + } ++#endif + + uart_port_unlock_irqrestore(&uap->port, flags); + } diff --git a/queue-6.12/serial-amba-pl011-fix-rx-stall-when-dma-is-used.patch b/queue-6.12/serial-amba-pl011-fix-rx-stall-when-dma-is-used.patch new file mode 100644 index 00000000000..1e099300f52 --- /dev/null +++ b/queue-6.12/serial-amba-pl011-fix-rx-stall-when-dma-is-used.patch @@ -0,0 +1,44 @@ +From 2bcacc1c87acf9a8ebc17de18cb2b3cfeca547cf Mon Sep 17 00:00:00 2001 +From: Kartik Rajput +Date: Wed, 13 Nov 2024 14:56:29 +0530 +Subject: serial: amba-pl011: Fix RX stall when DMA is used + +From: Kartik Rajput + +commit 2bcacc1c87acf9a8ebc17de18cb2b3cfeca547cf upstream. + +Function pl011_throttle_rx() calls pl011_stop_rx() to disable RX, which +also disables the RX DMA by clearing the RXDMAE bit of the DMACR +register. However, to properly unthrottle RX when DMA is used, the +function pl011_unthrottle_rx() is expected to set the RXDMAE bit of +the DMACR register, which it currently lacks. This causes RX to stall +after the throttle API is called. + +Set RXDMAE bit in the DMACR register while unthrottling RX if RX DMA is +used. + +Fixes: 211565b10099 ("serial: pl011: UPSTAT_AUTORTS requires .throttle/unthrottle") +Cc: stable@vger.kernel.org +Signed-off-by: Kartik Rajput +Reviewed-by: Linus Walleij +Link: https://lore.kernel.org/r/20241113092629.60226-1-kkartik@nvidia.com +Signed-off-by: Greg Kroah-Hartman +Signed-off-by: Greg Kroah-Hartman +--- + drivers/tty/serial/amba-pl011.c | 5 +++++ + 1 file changed, 5 insertions(+) + +--- a/drivers/tty/serial/amba-pl011.c ++++ b/drivers/tty/serial/amba-pl011.c +@@ -1819,6 +1819,11 @@ static void pl011_unthrottle_rx(struct u + + pl011_write(uap->im, uap, REG_IMSC); + ++ if (uap->using_rx_dma) { ++ uap->dmacr |= UART011_RXDMAE; ++ pl011_write(uap->dmacr, uap, REG_DMACR); ++ } ++ + uart_port_unlock_irqrestore(&uap->port, flags); + } + diff --git a/queue-6.12/series b/queue-6.12/series index 774bc739572..e338ce658af 100644 --- a/queue-6.12/series +++ b/queue-6.12/series @@ -703,3 +703,20 @@ risc-v-check-scalar-unaligned-access-on-all-cpus.patch ksmbd-fix-use-after-free-in-smb-request-handling.patch smb-client-fix-null-ptr-deref-in-crypto_aead_setkey.patch platform-chrome-cros_ec_typec-fix-missing-fwnode-reference-decrement.patch +irqchip-irq-mvebu-sei-move-misplaced-select-callback-to-sei-cp-domain.patch +x86-cpu-amd-terminate-the-erratum_1386_microcode-array.patch +ubi-wl-put-source-peb-into-correct-list-if-trying-locking-leb-failed.patch +um-ubd-do-not-use-drvdata-in-release.patch +um-net-do-not-use-drvdata-in-release.patch +dt-bindings-serial-rs485-fix-rs485-rts-delay-property.patch +serial-8250_fintek-add-support-for-f81216e.patch +serial-8250-omap-move-pm_runtime_get_sync.patch +serial-amba-pl011-fix-rx-stall-when-dma-is-used.patch +serial-amba-pl011-fix-build-regression.patch +revert-block-bfq-merge-bfq_release_process_ref-into-bfq_put_cooperator.patch +jffs2-prevent-rtime-decompress-memory-corruption.patch +mtd-ubi-fix-unreleased-fwnode_handle-in-find_volume_fwnode.patch +block-prevent-potential-deadlock-in-blk_revalidate_disk_zones.patch +um-vector-do-not-use-drvdata-in-release.patch +sh-cpuinfo-fix-a-warning-for-config_cpumask_offstack.patch +iio-gts-fix-uninitialized-symbol-ret.patch diff --git a/queue-6.12/sh-cpuinfo-fix-a-warning-for-config_cpumask_offstack.patch b/queue-6.12/sh-cpuinfo-fix-a-warning-for-config_cpumask_offstack.patch new file mode 100644 index 00000000000..e4aa40f4cac --- /dev/null +++ b/queue-6.12/sh-cpuinfo-fix-a-warning-for-config_cpumask_offstack.patch @@ -0,0 +1,64 @@ +From 3c891f7c6a4e90bb1199497552f24b26e46383bc Mon Sep 17 00:00:00 2001 +From: Huacai Chen +Date: Thu, 14 Jul 2022 16:41:36 +0800 +Subject: sh: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK + +From: Huacai Chen + +commit 3c891f7c6a4e90bb1199497552f24b26e46383bc upstream. + +When CONFIG_CPUMASK_OFFSTACK and CONFIG_DEBUG_PER_CPU_MAPS are selected, +cpu_max_bits_warn() generates a runtime warning similar as below when +showing /proc/cpuinfo. Fix this by using nr_cpu_ids (the runtime limit) +instead of NR_CPUS to iterate CPUs. + +[ 3.052463] ------------[ cut here ]------------ +[ 3.059679] WARNING: CPU: 3 PID: 1 at include/linux/cpumask.h:108 show_cpuinfo+0x5e8/0x5f0 +[ 3.070072] Modules linked in: efivarfs autofs4 +[ 3.076257] CPU: 0 PID: 1 Comm: systemd Not tainted 5.19-rc5+ #1052 +[ 3.099465] Stack : 9000000100157b08 9000000000f18530 9000000000cf846c 9000000100154000 +[ 3.109127] 9000000100157a50 0000000000000000 9000000100157a58 9000000000ef7430 +[ 3.118774] 90000001001578e8 0000000000000040 0000000000000020 ffffffffffffffff +[ 3.128412] 0000000000aaaaaa 1ab25f00eec96a37 900000010021de80 900000000101c890 +[ 3.138056] 0000000000000000 0000000000000000 0000000000000000 0000000000aaaaaa +[ 3.147711] ffff8000339dc220 0000000000000001 0000000006ab4000 0000000000000000 +[ 3.157364] 900000000101c998 0000000000000004 9000000000ef7430 0000000000000000 +[ 3.167012] 0000000000000009 000000000000006c 0000000000000000 0000000000000000 +[ 3.176641] 9000000000d3de08 9000000001639390 90000000002086d8 00007ffff0080286 +[ 3.186260] 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c +[ 3.195868] ... +[ 3.199917] Call Trace: +[ 3.203941] [<90000000002086d8>] show_stack+0x38/0x14c +[ 3.210666] [<9000000000cf846c>] dump_stack_lvl+0x60/0x88 +[ 3.217625] [<900000000023d268>] __warn+0xd0/0x100 +[ 3.223958] [<9000000000cf3c90>] warn_slowpath_fmt+0x7c/0xcc +[ 3.231150] [<9000000000210220>] show_cpuinfo+0x5e8/0x5f0 +[ 3.238080] [<90000000004f578c>] seq_read_iter+0x354/0x4b4 +[ 3.245098] [<90000000004c2e90>] new_sync_read+0x17c/0x1c4 +[ 3.252114] [<90000000004c5174>] vfs_read+0x138/0x1d0 +[ 3.258694] [<90000000004c55f8>] ksys_read+0x70/0x100 +[ 3.265265] [<9000000000cfde9c>] do_syscall+0x7c/0x94 +[ 3.271820] [<9000000000202fe4>] handle_syscall+0xc4/0x160 +[ 3.281824] ---[ end trace 8b484262b4b8c24c ]--- + +Cc: stable@vger.kernel.org +Signed-off-by: Huacai Chen +Reviewed-by: John Paul Adrian Glaubitz +Tested-by: John Paul Adrian Glaubitz +Signed-off-by: John Paul Adrian Glaubitz +Signed-off-by: Greg Kroah-Hartman +--- + arch/sh/kernel/cpu/proc.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/sh/kernel/cpu/proc.c ++++ b/arch/sh/kernel/cpu/proc.c +@@ -132,7 +132,7 @@ static int show_cpuinfo(struct seq_file + + static void *c_start(struct seq_file *m, loff_t *pos) + { +- return *pos < NR_CPUS ? cpu_data + *pos : NULL; ++ return *pos < nr_cpu_ids ? cpu_data + *pos : NULL; + } + static void *c_next(struct seq_file *m, void *v, loff_t *pos) + { diff --git a/queue-6.12/ubi-wl-put-source-peb-into-correct-list-if-trying-locking-leb-failed.patch b/queue-6.12/ubi-wl-put-source-peb-into-correct-list-if-trying-locking-leb-failed.patch new file mode 100644 index 00000000000..d0c64e3579a --- /dev/null +++ b/queue-6.12/ubi-wl-put-source-peb-into-correct-list-if-trying-locking-leb-failed.patch @@ -0,0 +1,61 @@ +From d610020f030bec819f42de327c2bd5437d2766b3 Mon Sep 17 00:00:00 2001 +From: Zhihao Cheng +Date: Mon, 19 Aug 2024 11:26:21 +0800 +Subject: ubi: wl: Put source PEB into correct list if trying locking LEB failed + +From: Zhihao Cheng + +commit d610020f030bec819f42de327c2bd5437d2766b3 upstream. + +During wear-leveing work, the source PEB will be moved into scrub list +when source LEB cannot be locked in ubi_eba_copy_leb(), which is wrong +for non-scrub type source PEB. The problem could bring extra and +ineffective wear-leveing jobs, which makes more or less negative effects +for the life time of flash. Specifically, the process is divided 2 steps: +1. wear_leveling_worker // generate false scrub type PEB + ubi_eba_copy_leb // MOVE_RETRY is returned + leb_write_trylock // trylock failed + scrubbing = 1; + e1 is put into ubi->scrub +2. wear_leveling_worker // schedule false scrub type PEB for wl + scrubbing = 1 + e1 = rb_entry(rb_first(&ubi->scrub)) + +The problem can be reproduced easily by running fsstress on a small +UBIFS partition(<64M, simulated by nandsim) for 5~10mins +(CONFIG_MTD_UBI_FASTMAP=y,CONFIG_MTD_UBI_WL_THRESHOLD=50). Following +message is shown: + ubi0: scrubbed PEB 66 (LEB 0:10), data moved to PEB 165 + +Since scrub type source PEB has set variable scrubbing as '1', and +variable scrubbing is checked before variable keep, so the problem can +be fixed by setting keep variable as 1 directly if the source LEB cannot +be locked. + +Fixes: e801e128b220 ("UBI: fix missing scrub when there is a bit-flip") +CC: stable@vger.kernel.org +Signed-off-by: Zhihao Cheng +Signed-off-by: Richard Weinberger +Signed-off-by: Greg Kroah-Hartman +--- + drivers/mtd/ubi/wl.c | 9 ++++++++- + 1 file changed, 8 insertions(+), 1 deletion(-) + +--- a/drivers/mtd/ubi/wl.c ++++ b/drivers/mtd/ubi/wl.c +@@ -846,7 +846,14 @@ static int wear_leveling_worker(struct u + goto out_not_moved; + } + if (err == MOVE_RETRY) { +- scrubbing = 1; ++ /* ++ * For source PEB: ++ * 1. The scrubbing is set for scrub type PEB, it will ++ * be put back into ubi->scrub list. ++ * 2. Non-scrub type PEB will be put back into ubi->used ++ * list. ++ */ ++ keep = 1; + dst_leb_clean = 1; + goto out_not_moved; + } diff --git a/queue-6.12/um-net-do-not-use-drvdata-in-release.patch b/queue-6.12/um-net-do-not-use-drvdata-in-release.patch new file mode 100644 index 00000000000..20c073b01b8 --- /dev/null +++ b/queue-6.12/um-net-do-not-use-drvdata-in-release.patch @@ -0,0 +1,74 @@ +From d1db692a9be3b4bd3473b64fcae996afaffe8438 Mon Sep 17 00:00:00 2001 +From: Tiwei Bie +Date: Tue, 5 Nov 2024 00:32:02 +0800 +Subject: um: net: Do not use drvdata in release + +From: Tiwei Bie + +commit d1db692a9be3b4bd3473b64fcae996afaffe8438 upstream. + +The drvdata is not available in release. Let's just use container_of() +to get the uml_net instance. Otherwise, removing a network device will +result in a crash: + +RIP: 0033:net_device_release+0x10/0x6f +RSP: 00000000e20c7c40 EFLAGS: 00010206 +RAX: 000000006002e4e7 RBX: 00000000600f1baf RCX: 00000000624074e0 +RDX: 0000000062778000 RSI: 0000000060551c80 RDI: 00000000627af028 +RBP: 00000000e20c7c50 R08: 00000000603ad594 R09: 00000000e20c7b70 +R10: 000000000000135a R11: 00000000603ad422 R12: 0000000000000000 +R13: 0000000062c7af00 R14: 0000000062406d60 R15: 00000000627700b6 +Kernel panic - not syncing: Segfault with no mm +CPU: 0 UID: 0 PID: 29 Comm: kworker/0:2 Not tainted 6.12.0-rc6-g59b723cd2adb #1 +Workqueue: events mc_work_proc +Stack: + 627af028 62c7af00 e20c7c80 60276fcd + 62778000 603f5820 627af028 00000000 + e20c7cb0 603a2bcd 627af000 62770010 +Call Trace: + [<60276fcd>] device_release+0x70/0xba + [<603a2bcd>] kobject_put+0xba/0xe7 + [<60277265>] put_device+0x19/0x1c + [<60281266>] platform_device_put+0x26/0x29 + [<60281e5f>] platform_device_unregister+0x2c/0x2e + [<6002ec9c>] net_remove+0x63/0x69 + [<60031316>] ? mconsole_reply+0x0/0x50 + [<600310c8>] mconsole_remove+0x160/0x1cc + [<60087d40>] ? __remove_hrtimer+0x38/0x74 + [<60087ff8>] ? hrtimer_try_to_cancel+0x8c/0x98 + [<6006b3cf>] ? dl_server_stop+0x3f/0x48 + [<6006b390>] ? dl_server_stop+0x0/0x48 + [<600672e8>] ? dequeue_entities+0x327/0x390 + [<60038fa6>] ? um_set_signals+0x0/0x43 + [<6003070c>] mc_work_proc+0x77/0x91 + [<60057664>] process_scheduled_works+0x1b3/0x2dd + [<60055f32>] ? assign_work+0x0/0x58 + [<60057f0a>] worker_thread+0x1e9/0x293 + [<6005406f>] ? set_pf_worker+0x0/0x64 + [<6005d65d>] ? arch_local_irq_save+0x0/0x2d + [<6005d748>] ? kthread_exit+0x0/0x3a + [<60057d21>] ? worker_thread+0x0/0x293 + [<6005dbf1>] kthread+0x126/0x12b + [<600219c5>] new_thread_handler+0x85/0xb6 + +Cc: stable@vger.kernel.org +Signed-off-by: Tiwei Bie +Acked-By: Anton Ivanov +Link: https://patch.msgid.link/20241104163203.435515-4-tiwei.btw@antgroup.com +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman +--- + arch/um/drivers/net_kern.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/um/drivers/net_kern.c ++++ b/arch/um/drivers/net_kern.c +@@ -336,7 +336,7 @@ static struct platform_driver uml_net_dr + + static void net_device_release(struct device *dev) + { +- struct uml_net *device = dev_get_drvdata(dev); ++ struct uml_net *device = container_of(dev, struct uml_net, pdev.dev); + struct net_device *netdev = device->dev; + struct uml_net_private *lp = netdev_priv(netdev); + diff --git a/queue-6.12/um-ubd-do-not-use-drvdata-in-release.patch b/queue-6.12/um-ubd-do-not-use-drvdata-in-release.patch new file mode 100644 index 00000000000..5dfeca14095 --- /dev/null +++ b/queue-6.12/um-ubd-do-not-use-drvdata-in-release.patch @@ -0,0 +1,78 @@ +From 5bee35e5389f450a7eea7318deb9073e9414d3b1 Mon Sep 17 00:00:00 2001 +From: Tiwei Bie +Date: Tue, 5 Nov 2024 00:32:01 +0800 +Subject: um: ubd: Do not use drvdata in release + +From: Tiwei Bie + +commit 5bee35e5389f450a7eea7318deb9073e9414d3b1 upstream. + +The drvdata is not available in release. Let's just use container_of() +to get the ubd instance. Otherwise, removing a ubd device will result +in a crash: + +RIP: 0033:blk_mq_free_tag_set+0x1f/0xba +RSP: 00000000e2083bf0 EFLAGS: 00010246 +RAX: 000000006021463a RBX: 0000000000000348 RCX: 0000000062604d00 +RDX: 0000000004208060 RSI: 00000000605241a0 RDI: 0000000000000348 +RBP: 00000000e2083c10 R08: 0000000062414010 R09: 00000000601603f7 +R10: 000000000000133a R11: 000000006038c4bd R12: 0000000000000000 +R13: 0000000060213a5c R14: 0000000062405d20 R15: 00000000604f7aa0 +Kernel panic - not syncing: Segfault with no mm +CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 6.8.0-rc3-00107-gba3f67c11638 #1 +Workqueue: events mc_work_proc +Stack: + 00000000 604f7ef0 62c5d000 62405d20 + e2083c30 6002c776 6002c755 600e47ff + e2083c60 6025ffe3 04208060 603d36e0 +Call Trace: + [<6002c776>] ubd_device_release+0x21/0x55 + [<6002c755>] ? ubd_device_release+0x0/0x55 + [<600e47ff>] ? kfree+0x0/0x100 + [<6025ffe3>] device_release+0x70/0xba + [<60381d6a>] kobject_put+0xb5/0xe2 + [<6026027b>] put_device+0x19/0x1c + [<6026a036>] platform_device_put+0x26/0x29 + [<6026ac5a>] platform_device_unregister+0x2c/0x2e + [<6002c52e>] ubd_remove+0xb8/0xd6 + [<6002bb74>] ? mconsole_reply+0x0/0x50 + [<6002b926>] mconsole_remove+0x160/0x1cc + [<6002bbbc>] ? mconsole_reply+0x48/0x50 + [<6003379c>] ? um_set_signals+0x3b/0x43 + [<60061c55>] ? update_min_vruntime+0x14/0x70 + [<6006251f>] ? dequeue_task_fair+0x164/0x235 + [<600620aa>] ? update_cfs_group+0x0/0x40 + [<603a0e77>] ? __schedule+0x0/0x3ed + [<60033761>] ? um_set_signals+0x0/0x43 + [<6002af6a>] mc_work_proc+0x77/0x91 + [<600520b4>] process_scheduled_works+0x1af/0x2c3 + [<6004ede3>] ? assign_work+0x0/0x58 + [<600527a1>] worker_thread+0x2f7/0x37a + [<6004ee3b>] ? set_pf_worker+0x0/0x64 + [<6005765d>] ? arch_local_irq_save+0x0/0x2d + [<60058e07>] ? kthread_exit+0x0/0x3a + [<600524aa>] ? worker_thread+0x0/0x37a + [<60058f9f>] kthread+0x130/0x135 + [<6002068e>] new_thread_handler+0x85/0xb6 + +Cc: stable@vger.kernel.org +Signed-off-by: Tiwei Bie +Acked-By: Anton Ivanov +Link: https://patch.msgid.link/20241104163203.435515-3-tiwei.btw@antgroup.com +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman +--- + arch/um/drivers/ubd_kern.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/arch/um/drivers/ubd_kern.c ++++ b/arch/um/drivers/ubd_kern.c +@@ -779,7 +779,7 @@ static int ubd_open_dev(struct ubd *ubd_ + + static void ubd_device_release(struct device *dev) + { +- struct ubd *ubd_dev = dev_get_drvdata(dev); ++ struct ubd *ubd_dev = container_of(dev, struct ubd, pdev.dev); + + blk_mq_free_tag_set(&ubd_dev->tag_set); + *ubd_dev = ((struct ubd) DEFAULT_UBD); diff --git a/queue-6.12/um-vector-do-not-use-drvdata-in-release.patch b/queue-6.12/um-vector-do-not-use-drvdata-in-release.patch new file mode 100644 index 00000000000..682730a7e6b --- /dev/null +++ b/queue-6.12/um-vector-do-not-use-drvdata-in-release.patch @@ -0,0 +1,75 @@ +From 51b39d741970742a5c41136241a9c48ac607cf82 Mon Sep 17 00:00:00 2001 +From: Tiwei Bie +Date: Tue, 5 Nov 2024 00:32:03 +0800 +Subject: um: vector: Do not use drvdata in release + +From: Tiwei Bie + +commit 51b39d741970742a5c41136241a9c48ac607cf82 upstream. + +The drvdata is not available in release. Let's just use container_of() +to get the vector_device instance. Otherwise, removing a vector device +will result in a crash: + +RIP: 0033:vector_device_release+0xf/0x50 +RSP: 00000000e187bc40 EFLAGS: 00010202 +RAX: 0000000060028f61 RBX: 00000000600f1baf RCX: 00000000620074e0 +RDX: 000000006220b9c0 RSI: 0000000060551c80 RDI: 0000000000000000 +RBP: 00000000e187bc50 R08: 00000000603ad594 R09: 00000000e187bb70 +R10: 000000000000135a R11: 00000000603ad422 R12: 00000000623ae028 +R13: 000000006287a200 R14: 0000000062006d30 R15: 00000000623700b6 +Kernel panic - not syncing: Segfault with no mm +CPU: 0 UID: 0 PID: 16 Comm: kworker/0:1 Not tainted 6.12.0-rc6-g59b723cd2adb #1 +Workqueue: events mc_work_proc +Stack: + 60028f61 623ae028 e187bc80 60276fcd + 6220b9c0 603f5820 623ae028 00000000 + e187bcb0 603a2bcd 623ae000 62370010 +Call Trace: + [<60028f61>] ? vector_device_release+0x0/0x50 + [<60276fcd>] device_release+0x70/0xba + [<603a2bcd>] kobject_put+0xba/0xe7 + [<60277265>] put_device+0x19/0x1c + [<60281266>] platform_device_put+0x26/0x29 + [<60281e5f>] platform_device_unregister+0x2c/0x2e + [<60029422>] vector_remove+0x52/0x58 + [<60031316>] ? mconsole_reply+0x0/0x50 + [<600310c8>] mconsole_remove+0x160/0x1cc + [<603b19f4>] ? strlen+0x0/0x15 + [<60066611>] ? __dequeue_entity+0x1a9/0x206 + [<600666a7>] ? set_next_entity+0x39/0x63 + [<6006666e>] ? set_next_entity+0x0/0x63 + [<60038fa6>] ? um_set_signals+0x0/0x43 + [<6003070c>] mc_work_proc+0x77/0x91 + [<60057664>] process_scheduled_works+0x1b3/0x2dd + [<60055f32>] ? assign_work+0x0/0x58 + [<60057f0a>] worker_thread+0x1e9/0x293 + [<6005406f>] ? set_pf_worker+0x0/0x64 + [<6005d65d>] ? arch_local_irq_save+0x0/0x2d + [<6005d748>] ? kthread_exit+0x0/0x3a + [<60057d21>] ? worker_thread+0x0/0x293 + [<6005dbf1>] kthread+0x126/0x12b + [<600219c5>] new_thread_handler+0x85/0xb6 + +Cc: stable@vger.kernel.org +Signed-off-by: Tiwei Bie +Acked-By: Anton Ivanov +Link: https://patch.msgid.link/20241104163203.435515-5-tiwei.btw@antgroup.com +Signed-off-by: Johannes Berg +Signed-off-by: Greg Kroah-Hartman +--- + arch/um/drivers/vector_kern.c | 3 ++- + 1 file changed, 2 insertions(+), 1 deletion(-) + +--- a/arch/um/drivers/vector_kern.c ++++ b/arch/um/drivers/vector_kern.c +@@ -815,7 +815,8 @@ static struct platform_driver uml_net_dr + + static void vector_device_release(struct device *dev) + { +- struct vector_device *device = dev_get_drvdata(dev); ++ struct vector_device *device = ++ container_of(dev, struct vector_device, pdev.dev); + struct net_device *netdev = device->dev; + + list_del(&device->list); diff --git a/queue-6.12/x86-cpu-amd-terminate-the-erratum_1386_microcode-array.patch b/queue-6.12/x86-cpu-amd-terminate-the-erratum_1386_microcode-array.patch new file mode 100644 index 00000000000..4d8785339c7 --- /dev/null +++ b/queue-6.12/x86-cpu-amd-terminate-the-erratum_1386_microcode-array.patch @@ -0,0 +1,35 @@ +From ff6cdc407f4179748f4673c39b0921503199a0ad Mon Sep 17 00:00:00 2001 +From: Sebastian Andrzej Siewior +Date: Tue, 26 Nov 2024 14:47:22 +0100 +Subject: x86/CPU/AMD: Terminate the erratum_1386_microcode array + +From: Sebastian Andrzej Siewior + +commit ff6cdc407f4179748f4673c39b0921503199a0ad upstream. + +The erratum_1386_microcode array requires an empty entry at the end. +Otherwise x86_match_cpu_with_stepping() will continue iterate the array after +it ended. + +Add an empty entry to erratum_1386_microcode to its end. + +Fixes: 29ba89f189528 ("x86/CPU/AMD: Improve the erratum 1386 workaround") +Signed-off-by: Sebastian Andrzej Siewior +Signed-off-by: Borislav Petkov (AMD) +Cc: +Link: https://lore.kernel.org/r/20241126134722.480975-1-bigeasy@linutronix.de +Signed-off-by: Greg Kroah-Hartman +--- + arch/x86/kernel/cpu/amd.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/arch/x86/kernel/cpu/amd.c ++++ b/arch/x86/kernel/cpu/amd.c +@@ -798,6 +798,7 @@ static void init_amd_bd(struct cpuinfo_x + static const struct x86_cpu_desc erratum_1386_microcode[] = { + AMD_CPU_DESC(0x17, 0x1, 0x2, 0x0800126e), + AMD_CPU_DESC(0x17, 0x31, 0x0, 0x08301052), ++ {}, + }; + + static void fix_erratum_1386(struct cpuinfo_x86 *c) -- 2.47.3