--- /dev/null
+From 0b83c86b444ab467134b0e618f45ad2216a4973c Mon Sep 17 00:00:00 2001
+From: Damien Le Moal <dlemoal@kernel.org>
+Date: Tue, 26 Nov 2024 19:47:05 +0900
+Subject: block: Prevent potential deadlock in blk_revalidate_disk_zones()
+
+From: Damien Le Moal <dlemoal@kernel.org>
+
+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 <dlemoal@kernel.org>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Link: https://lore.kernel.org/r/20241126104705.183996-1-dlemoal@kernel.org
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+
--- /dev/null
+From 12b3642b6c242061d3ba84e6e3050c3141ded14c Mon Sep 17 00:00:00 2001
+From: Michal Simek <michal.simek@amd.com>
+Date: Mon, 16 Sep 2024 11:53:06 +0200
+Subject: dt-bindings: serial: rs485: Fix rs485-rts-delay property
+
+From: Michal Simek <michal.simek@amd.com>
+
+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 <michal.simek@amd.com>
+Cc: stable@vger.kernel.org
+Reviewed-by: Krzysztof Kozlowski <krzk@kernel.org>
+Link: https://lore.kernel.org/r/820c639b9e22fe037730ed44d1b044cdb6d28b75.1726480384.git.michal.simek@amd.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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 <a b>
+ $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).
--- /dev/null
+From e2fb2f89faf87b681038475d093214f4cbe12ebb Mon Sep 17 00:00:00 2001
+From: Zicheng Qu <quzicheng@huawei.com>
+Date: Thu, 31 Oct 2024 01:45:05 +0000
+Subject: iio: gts: Fix uninitialized symbol 'ret'
+
+From: Zicheng Qu <quzicheng@huawei.com>
+
+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 <quzicheng@huawei.com>
+Reviewed-by: Matti Vaittinen <mazziesaccount@gmail.com>
+Link: https://patch.msgid.link/20241031014505.2313035-1-quzicheng@huawei.com
+Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+
--- /dev/null
+From 12aaf67584cf19dc84615b7aba272fe642c35b8b Mon Sep 17 00:00:00 2001
+From: "Russell King (Oracle)" <rmk+kernel@armlinux.org.uk>
+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) <rmk+kernel@armlinux.org.uk>
+
+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) <rmk+kernel@armlinux.org.uk>
+Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
+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 <gregkh@linuxfoundation.org>
+---
+ 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,
+ };
--- /dev/null
+From fe051552f5078fa02d593847529a3884305a6ffe Mon Sep 17 00:00:00 2001
+From: Kinsey Moore <kinsey.moore@oarcorp.com>
+Date: Tue, 23 Jul 2024 15:58:05 -0500
+Subject: jffs2: Prevent rtime decompress memory corruption
+
+From: Kinsey Moore <kinsey.moore@oarcorp.com>
+
+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 <kinsey.moore@oarcorp.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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++];
--- /dev/null
+From 07593293ffabba14125c8998525adde5a832bfa3 Mon Sep 17 00:00:00 2001
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+Date: Sat, 19 Oct 2024 22:27:03 +0200
+Subject: mtd: ubi: fix unreleased fwnode_handle in find_volume_fwnode()
+
+From: Javier Carrasco <javier.carrasco.cruz@gmail.com>
+
+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 <javier.carrasco.cruz@gmail.com>
+Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From cf5a60d971c7b59efb89927919404be655a9e35a Mon Sep 17 00:00:00 2001
+From: Zach Wade <zachwade.k@gmail.com>
+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 <zachwade.k@gmail.com>
+
+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] <TASK>
+[ 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] </TASK>
+[ 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 <zachwade.k@gmail.com>
+Cc: Ding Hui <dinghui@sangfor.com.cn>
+Reviewed-by: Yu Kuai <yukuai3@huawei.com>
+Link: https://lore.kernel.org/r/20241119153410.2546-1-zachwade.k@gmail.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+
--- /dev/null
+From bcc7ba668818dcadd2f1db66b39ed860a63ecf97 Mon Sep 17 00:00:00 2001
+From: Bin Liu <b-liu@ti.com>
+Date: Thu, 31 Oct 2024 12:23:15 -0500
+Subject: serial: 8250: omap: Move pm_runtime_get_sync
+
+From: Bin Liu <b-liu@ti.com>
+
+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 <b-liu@ti.com>
+[Judith: Add commit message]
+Signed-off-by: Judith Mendez <jm@ti.com>
+Reviewed-by: Kevin Hilman <khilman@baylibre.com>
+Tested-by: Kevin Hilman <khilman@baylibre.com>
+Link: https://lore.kernel.org/r/20241031172315.453750-1-jm@ti.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 166105c9030a30ba08574a9998afc7b60bc72dd7 Mon Sep 17 00:00:00 2001
+From: Filip Brozovic <fbrozovic@gmail.com>
+Date: Sun, 10 Nov 2024 12:17:00 +0100
+Subject: serial: 8250_fintek: Add support for F81216E
+
+From: Filip Brozovic <fbrozovic@gmail.com>
+
+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 <fbrozovic@gmail.com>
+Cc: stable <stable@kernel.org>
+Link: https://lore.kernel.org/r/20241110111703.15494-1-fbrozovic@gmail.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From b5a23a60e8ab5711f4952912424347bf3864ce8d Mon Sep 17 00:00:00 2001
+From: Arnd Bergmann <arnd@arndb.de>
+Date: Fri, 15 Nov 2024 11:59:54 +0100
+Subject: serial: amba-pl011: fix build regression
+
+From: Arnd Bergmann <arnd@arndb.de>
+
+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 <stable@kernel.org>
+Reported-by: kernel test robot <lkp@intel.com>
+Closes: https://lore.kernel.org/oe-kbuild-all/202411140617.nkjeHhsK-lkp@intel.com/
+Signed-off-by: Arnd Bergmann <arnd@arndb.de>
+Link: https://lore.kernel.org/r/20241115110021.744332-1-arnd@kernel.org
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
--- /dev/null
+From 2bcacc1c87acf9a8ebc17de18cb2b3cfeca547cf Mon Sep 17 00:00:00 2001
+From: Kartik Rajput <kkartik@nvidia.com>
+Date: Wed, 13 Nov 2024 14:56:29 +0530
+Subject: serial: amba-pl011: Fix RX stall when DMA is used
+
+From: Kartik Rajput <kkartik@nvidia.com>
+
+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 <kkartik@nvidia.com>
+Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
+Link: https://lore.kernel.org/r/20241113092629.60226-1-kkartik@nvidia.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+ }
+
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
--- /dev/null
+From 3c891f7c6a4e90bb1199497552f24b26e46383bc Mon Sep 17 00:00:00 2001
+From: Huacai Chen <chenhuacai@loongson.cn>
+Date: Thu, 14 Jul 2022 16:41:36 +0800
+Subject: sh: cpuinfo: Fix a warning for CONFIG_CPUMASK_OFFSTACK
+
+From: Huacai Chen <chenhuacai@loongson.cn>
+
+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 <chenhuacai@loongson.cn>
+Reviewed-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
+Tested-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
+Signed-off-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
+ {
--- /dev/null
+From d610020f030bec819f42de327c2bd5437d2766b3 Mon Sep 17 00:00:00 2001
+From: Zhihao Cheng <chengzhihao1@huawei.com>
+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 <chengzhihao1@huawei.com>
+
+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 <chengzhihao1@huawei.com>
+Signed-off-by: Richard Weinberger <richard@nod.at>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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;
+ }
--- /dev/null
+From d1db692a9be3b4bd3473b64fcae996afaffe8438 Mon Sep 17 00:00:00 2001
+From: Tiwei Bie <tiwei.btw@antgroup.com>
+Date: Tue, 5 Nov 2024 00:32:02 +0800
+Subject: um: net: Do not use drvdata in release
+
+From: Tiwei Bie <tiwei.btw@antgroup.com>
+
+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 <tiwei.btw@antgroup.com>
+Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
+Link: https://patch.msgid.link/20241104163203.435515-4-tiwei.btw@antgroup.com
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
+
--- /dev/null
+From 5bee35e5389f450a7eea7318deb9073e9414d3b1 Mon Sep 17 00:00:00 2001
+From: Tiwei Bie <tiwei.btw@antgroup.com>
+Date: Tue, 5 Nov 2024 00:32:01 +0800
+Subject: um: ubd: Do not use drvdata in release
+
+From: Tiwei Bie <tiwei.btw@antgroup.com>
+
+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 <tiwei.btw@antgroup.com>
+Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
+Link: https://patch.msgid.link/20241104163203.435515-3-tiwei.btw@antgroup.com
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From 51b39d741970742a5c41136241a9c48ac607cf82 Mon Sep 17 00:00:00 2001
+From: Tiwei Bie <tiwei.btw@antgroup.com>
+Date: Tue, 5 Nov 2024 00:32:03 +0800
+Subject: um: vector: Do not use drvdata in release
+
+From: Tiwei Bie <tiwei.btw@antgroup.com>
+
+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 <tiwei.btw@antgroup.com>
+Acked-By: Anton Ivanov <anton.ivanov@cambridgegreys.com>
+Link: https://patch.msgid.link/20241104163203.435515-5-tiwei.btw@antgroup.com
+Signed-off-by: Johannes Berg <johannes.berg@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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);
--- /dev/null
+From ff6cdc407f4179748f4673c39b0921503199a0ad Mon Sep 17 00:00:00 2001
+From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Date: Tue, 26 Nov 2024 14:47:22 +0100
+Subject: x86/CPU/AMD: Terminate the erratum_1386_microcode array
+
+From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+
+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 <bigeasy@linutronix.de>
+Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
+Cc: <stable@kernel.org>
+Link: https://lore.kernel.org/r/20241126134722.480975-1-bigeasy@linutronix.de
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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)
projects / thirdparty / kernel / stable-queue.git / commitdiff
