--- /dev/null
+From 2a19b28f7929866e1cec92a3619f4de9f2d20005 Mon Sep 17 00:00:00 2001
+From: Ming Lei <ming.lei@redhat.com>
+Date: Tue, 16 Nov 2021 09:43:43 +0800
+Subject: blk-mq: cancel blk-mq dispatch work in both blk_cleanup_queue and disk_release()
+
+From: Ming Lei <ming.lei@redhat.com>
+
+commit 2a19b28f7929866e1cec92a3619f4de9f2d20005 upstream.
+
+For avoiding to slow down queue destroy, we don't call
+blk_mq_quiesce_queue() in blk_cleanup_queue(), instead of delaying to
+cancel dispatch work in blk_release_queue().
+
+However, this way has caused kernel oops[1], reported by Changhui. The log
+shows that scsi_device can be freed before running blk_release_queue(),
+which is expected too since scsi_device is released after the scsi disk
+is closed and the scsi_device is removed.
+
+Fixes the issue by canceling blk-mq dispatch work in both blk_cleanup_queue()
+and disk_release():
+
+1) when disk_release() is run, the disk has been closed, and any sync
+dispatch activities have been done, so canceling dispatch work is enough to
+quiesce filesystem I/O dispatch activity.
+
+2) in blk_cleanup_queue(), we only focus on passthrough request, and
+passthrough request is always explicitly allocated & freed by
+its caller, so once queue is frozen, all sync dispatch activity
+for passthrough request has been done, then it is enough to just cancel
+dispatch work for avoiding any dispatch activity.
+
+[1] kernel panic log
+[12622.769416] BUG: kernel NULL pointer dereference, address: 0000000000000300
+[12622.777186] #PF: supervisor read access in kernel mode
+[12622.782918] #PF: error_code(0x0000) - not-present page
+[12622.788649] PGD 0 P4D 0
+[12622.791474] Oops: 0000 [#1] PREEMPT SMP PTI
+[12622.796138] CPU: 10 PID: 744 Comm: kworker/10:1H Kdump: loaded Not tainted 5.15.0+ #1
+[12622.804877] Hardware name: Dell Inc. PowerEdge R730/0H21J3, BIOS 1.5.4 10/002/2015
+[12622.813321] Workqueue: kblockd blk_mq_run_work_fn
+[12622.818572] RIP: 0010:sbitmap_get+0x75/0x190
+[12622.823336] Code: 85 80 00 00 00 41 8b 57 08 85 d2 0f 84 b1 00 00 00 45 31 e4 48 63 cd 48 8d 1c 49 48 c1 e3 06 49 03 5f 10 4c 8d 6b 40 83 f0 01 <48> 8b 33 44 89 f2 4c 89 ef 0f b6 c8 e8 fa f3 ff ff 83 f8 ff 75 58
+[12622.844290] RSP: 0018:ffffb00a446dbd40 EFLAGS: 00010202
+[12622.850120] RAX: 0000000000000001 RBX: 0000000000000300 RCX: 0000000000000004
+[12622.858082] RDX: 0000000000000006 RSI: 0000000000000082 RDI: ffffa0b7a2dfe030
+[12622.866042] RBP: 0000000000000004 R08: 0000000000000001 R09: ffffa0b742721334
+[12622.874003] R10: 0000000000000008 R11: 0000000000000008 R12: 0000000000000000
+[12622.881964] R13: 0000000000000340 R14: 0000000000000000 R15: ffffa0b7a2dfe030
+[12622.889926] FS: 0000000000000000(0000) GS:ffffa0baafb40000(0000) knlGS:0000000000000000
+[12622.898956] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[12622.905367] CR2: 0000000000000300 CR3: 0000000641210001 CR4: 00000000001706e0
+[12622.913328] Call Trace:
+[12622.916055] <TASK>
+[12622.918394] scsi_mq_get_budget+0x1a/0x110
+[12622.922969] __blk_mq_do_dispatch_sched+0x1d4/0x320
+[12622.928404] ? pick_next_task_fair+0x39/0x390
+[12622.933268] __blk_mq_sched_dispatch_requests+0xf4/0x140
+[12622.939194] blk_mq_sched_dispatch_requests+0x30/0x60
+[12622.944829] __blk_mq_run_hw_queue+0x30/0xa0
+[12622.949593] process_one_work+0x1e8/0x3c0
+[12622.954059] worker_thread+0x50/0x3b0
+[12622.958144] ? rescuer_thread+0x370/0x370
+[12622.962616] kthread+0x158/0x180
+[12622.966218] ? set_kthread_struct+0x40/0x40
+[12622.970884] ret_from_fork+0x22/0x30
+[12622.974875] </TASK>
+[12622.977309] Modules linked in: scsi_debug rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs sunrpc dm_multipath intel_rapl_msr intel_rapl_common dell_wmi_descriptor sb_edac rfkill video x86_pkg_temp_thermal intel_powerclamp dcdbas coretemp kvm_intel kvm mgag200 irqbypass i2c_algo_bit rapl drm_kms_helper ipmi_ssif intel_cstate intel_uncore syscopyarea sysfillrect sysimgblt fb_sys_fops pcspkr cec mei_me lpc_ich mei ipmi_si ipmi_devintf ipmi_msghandler acpi_power_meter drm fuse xfs libcrc32c sr_mod cdrom sd_mod t10_pi sg ixgbe ahci libahci crct10dif_pclmul crc32_pclmul crc32c_intel libata megaraid_sas ghash_clmulni_intel tg3 wdat_wdt mdio dca wmi dm_mirror dm_region_hash dm_log dm_mod [last unloaded: scsi_debug]
+
+Reported-by: ChanghuiZhong <czhong@redhat.com>
+Cc: Christoph Hellwig <hch@lst.de>
+Cc: "Martin K. Petersen" <martin.petersen@oracle.com>
+Cc: Bart Van Assche <bvanassche@acm.org>
+Cc: linux-scsi@vger.kernel.org
+Signed-off-by: Ming Lei <ming.lei@redhat.com>
+Link: https://lore.kernel.org/r/20211116014343.610501-1-ming.lei@redhat.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ block/blk-core.c | 4 +++-
+ block/blk-mq.c | 13 +++++++++++++
+ block/blk-mq.h | 2 ++
+ block/blk-sysfs.c | 10 ----------
+ block/genhd.c | 2 ++
+ 5 files changed, 20 insertions(+), 11 deletions(-)
+
+--- a/block/blk-core.c
++++ b/block/blk-core.c
+@@ -389,8 +389,10 @@ void blk_cleanup_queue(struct request_qu
+ blk_queue_flag_set(QUEUE_FLAG_DEAD, q);
+
+ blk_sync_queue(q);
+- if (queue_is_mq(q))
++ if (queue_is_mq(q)) {
++ blk_mq_cancel_work_sync(q);
+ blk_mq_exit_queue(q);
++ }
+
+ /*
+ * In theory, request pool of sched_tags belongs to request queue.
+--- a/block/blk-mq.c
++++ b/block/blk-mq.c
+@@ -4018,6 +4018,19 @@ unsigned int blk_mq_rq_cpu(struct reques
+ }
+ EXPORT_SYMBOL(blk_mq_rq_cpu);
+
++void blk_mq_cancel_work_sync(struct request_queue *q)
++{
++ if (queue_is_mq(q)) {
++ struct blk_mq_hw_ctx *hctx;
++ int i;
++
++ cancel_delayed_work_sync(&q->requeue_work);
++
++ queue_for_each_hw_ctx(q, hctx, i)
++ cancel_delayed_work_sync(&hctx->run_work);
++ }
++}
++
+ static int __init blk_mq_init(void)
+ {
+ int i;
+--- a/block/blk-mq.h
++++ b/block/blk-mq.h
+@@ -129,6 +129,8 @@ extern int blk_mq_sysfs_register(struct
+ extern void blk_mq_sysfs_unregister(struct request_queue *q);
+ extern void blk_mq_hctx_kobj_init(struct blk_mq_hw_ctx *hctx);
+
++void blk_mq_cancel_work_sync(struct request_queue *q);
++
+ void blk_mq_release(struct request_queue *q);
+
+ static inline struct blk_mq_ctx *__blk_mq_get_ctx(struct request_queue *q,
+--- a/block/blk-sysfs.c
++++ b/block/blk-sysfs.c
+@@ -805,16 +805,6 @@ static void blk_release_queue(struct kob
+
+ blk_free_queue_stats(q->stats);
+
+- if (queue_is_mq(q)) {
+- struct blk_mq_hw_ctx *hctx;
+- int i;
+-
+- cancel_delayed_work_sync(&q->requeue_work);
+-
+- queue_for_each_hw_ctx(q, hctx, i)
+- cancel_delayed_work_sync(&hctx->run_work);
+- }
+-
+ blk_exit_queue(q);
+
+ blk_queue_free_zone_bitmaps(q);
+--- a/block/genhd.c
++++ b/block/genhd.c
+@@ -1086,6 +1086,8 @@ static void disk_release(struct device *
+ might_sleep();
+ WARN_ON_ONCE(disk_live(disk));
+
++ blk_mq_cancel_work_sync(disk->queue);
++
+ disk_release_events(disk);
+ kfree(disk->random);
+ xa_destroy(&disk->part_tbl);
--- /dev/null
+From 245a489e81e13dd55ae46d27becf6d5901eb7828 Mon Sep 17 00:00:00 2001
+From: Ming Lei <ming.lei@redhat.com>
+Date: Wed, 17 Nov 2021 19:55:02 +0800
+Subject: block: avoid to quiesce queue in elevator_init_mq
+
+From: Ming Lei <ming.lei@redhat.com>
+
+commit 245a489e81e13dd55ae46d27becf6d5901eb7828 upstream.
+
+elevator_init_mq() is only called before adding disk, when there isn't
+any FS I/O, only passthrough requests can be queued, so freezing queue
+plus canceling dispatch work is enough to drain any dispatch activities,
+then we can avoid synchronize_srcu() in blk_mq_quiesce_queue().
+
+Long boot latency issue can be fixed in case of lots of disks added
+during booting.
+
+Fixes: 737eb78e82d5 ("block: Delay default elevator initialization")
+Reported-by: yangerkun <yangerkun@huawei.com>
+Cc: Damien Le Moal <damien.lemoal@wdc.com>
+Signed-off-by: Ming Lei <ming.lei@redhat.com>
+Link: https://lore.kernel.org/r/20211117115502.1600950-1-ming.lei@redhat.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ block/elevator.c | 10 ++++++++--
+ 1 file changed, 8 insertions(+), 2 deletions(-)
+
+--- a/block/elevator.c
++++ b/block/elevator.c
+@@ -694,12 +694,18 @@ void elevator_init_mq(struct request_que
+ if (!e)
+ return;
+
++ /*
++ * We are called before adding disk, when there isn't any FS I/O,
++ * so freezing queue plus canceling dispatch work is enough to
++ * drain any dispatch activities originated from passthrough
++ * requests, then no need to quiesce queue which may add long boot
++ * latency, especially when lots of disks are involved.
++ */
+ blk_mq_freeze_queue(q);
+- blk_mq_quiesce_queue(q);
++ blk_mq_cancel_work_sync(q);
+
+ err = blk_mq_init_sched(q, e);
+
+- blk_mq_unquiesce_queue(q);
+ blk_mq_unfreeze_queue(q);
+
+ if (err) {
--- /dev/null
+From 0f60a29c52b515532e6b11dc6b3c9e5b5f7ff2b4 Mon Sep 17 00:00:00 2001
+From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Date: Tue, 16 Nov 2021 12:11:21 +0000
+Subject: docs: accounting: update delay-accounting.rst reference
+
+From: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+
+commit 0f60a29c52b515532e6b11dc6b3c9e5b5f7ff2b4 upstream.
+
+The file name: accounting/delay-accounting.rst
+should be, instead: Documentation/accounting/delay-accounting.rst.
+
+Also, there's no need to use doc:`foo`, as automarkup.py will
+automatically handle plain text mentions to Documentation/
+files.
+
+So, update its cross-reference accordingly.
+
+Fixes: fcb501704554 ("delayacct: Document task_delayacct sysctl")
+Fixes: c3123552aad3 ("docs: accounting: convert to ReST")
+Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
+Signed-off-by: Jonathan Corbet <corbet@lwn.net>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ Documentation/admin-guide/sysctl/kernel.rst | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/Documentation/admin-guide/sysctl/kernel.rst
++++ b/Documentation/admin-guide/sysctl/kernel.rst
+@@ -1099,7 +1099,7 @@ task_delayacct
+ ===============
+
+ Enables/disables task delay accounting (see
+-:doc:`accounting/delay-accounting.rst`). Enabling this feature incurs
++Documentation/accounting/delay-accounting.rst. Enabling this feature incurs
+ a small amount of overhead in the scheduler but is useful for debugging
+ and performance tuning. It is required by some tools such as iotop.
+
--- /dev/null
+From 026d9835b62bba34b7e657a0bfb76717822f9319 Mon Sep 17 00:00:00 2001
+From: Cristian Marussi <cristian.marussi@arm.com>
+Date: Mon, 15 Nov 2021 15:40:42 +0000
+Subject: firmware: arm_scmi: Fix type error assignment in voltage protocol
+
+From: Cristian Marussi <cristian.marussi@arm.com>
+
+commit 026d9835b62bba34b7e657a0bfb76717822f9319 upstream.
+
+Fix incorrect type assignment error reported by sparse as:
+
+drivers/firmware/arm_scmi/voltage.c:159:42: warning: incorrect type in assignment (different base types)
+drivers/firmware/arm_scmi/voltage.c:159:42: expected restricted __le32 [usertype] level_index
+drivers/firmware/arm_scmi/voltage.c:159:42: got unsigned int [usertype] desc_index
+
+Link: https://lore.kernel.org/r/20211115154043.49284-1-cristian.marussi@arm.com
+Fixes: 2add5cacff353 ("firmware: arm_scmi: Add voltage domain management protocol support")
+Reported-by: kernel test robot <lkp@intel.com>
+Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
+Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/arm_scmi/voltage.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/firmware/arm_scmi/voltage.c
++++ b/drivers/firmware/arm_scmi/voltage.c
+@@ -156,7 +156,7 @@ static int scmi_voltage_descriptors_get(
+ int cnt;
+
+ cmd->domain_id = cpu_to_le32(v->id);
+- cmd->level_index = desc_index;
++ cmd->level_index = cpu_to_le32(desc_index);
+ ret = ph->xops->do_xfer(ph, tl);
+ if (ret)
+ break;
--- /dev/null
+From bd074e5039ee16d71833a67337e2f6bf5d106b3a Mon Sep 17 00:00:00 2001
+From: Cristian Marussi <cristian.marussi@arm.com>
+Date: Mon, 15 Nov 2021 15:40:43 +0000
+Subject: firmware: arm_scmi: Fix type error in sensor protocol
+
+From: Cristian Marussi <cristian.marussi@arm.com>
+
+commit bd074e5039ee16d71833a67337e2f6bf5d106b3a upstream.
+
+Fix incorrect type error reported by sparse as:
+
+drivers/firmware/arm_scmi/sensors.c:640:28: warning: incorrect type in argument 1 (different base types)
+drivers/firmware/arm_scmi/sensors.c:640:28: expected unsigned int [usertype] val
+drivers/firmware/arm_scmi/sensors.c:640:28: got restricted __le32 [usertype]
+
+Link: https://lore.kernel.org/r/20211115154043.49284-2-cristian.marussi@arm.com
+Fixes: 7b83c5f410889 ("firmware: arm_scmi: Add SCMI v3.0 sensor configuration support")
+Signed-off-by: Cristian Marussi <cristian.marussi@arm.com>
+Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/firmware/arm_scmi/sensors.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/drivers/firmware/arm_scmi/sensors.c
++++ b/drivers/firmware/arm_scmi/sensors.c
+@@ -637,7 +637,7 @@ static int scmi_sensor_config_get(const
+ if (ret)
+ return ret;
+
+- put_unaligned_le32(cpu_to_le32(sensor_id), t->tx.buf);
++ put_unaligned_le32(sensor_id, t->tx.buf);
+ ret = ph->xops->do_xfer(ph, t);
+ if (!ret) {
+ struct sensors_info *si = ph->get_priv(ph);
--- /dev/null
+From 1d0254e6b47e73222fd3d6ae95cccbaafe5b3ecf Mon Sep 17 00:00:00 2001
+From: Ye Bin <yebin10@huawei.com>
+Date: Mon, 22 Nov 2021 10:47:37 +0800
+Subject: io_uring: fix soft lockup when call __io_remove_buffers
+
+From: Ye Bin <yebin10@huawei.com>
+
+commit 1d0254e6b47e73222fd3d6ae95cccbaafe5b3ecf upstream.
+
+I got issue as follows:
+[ 567.094140] __io_remove_buffers: [1]start ctx=0xffff8881067bf000 bgid=65533 buf=0xffff8881fefe1680
+[ 594.360799] watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [kworker/u32:5:108]
+[ 594.364987] Modules linked in:
+[ 594.365405] irq event stamp: 604180238
+[ 594.365906] hardirqs last enabled at (604180237): [<ffffffff93fec9bd>] _raw_spin_unlock_irqrestore+0x2d/0x50
+[ 594.367181] hardirqs last disabled at (604180238): [<ffffffff93fbbadb>] sysvec_apic_timer_interrupt+0xb/0xc0
+[ 594.368420] softirqs last enabled at (569080666): [<ffffffff94200654>] __do_softirq+0x654/0xa9e
+[ 594.369551] softirqs last disabled at (569080575): [<ffffffff913e1d6a>] irq_exit_rcu+0x1ca/0x250
+[ 594.370692] CPU: 2 PID: 108 Comm: kworker/u32:5 Tainted: G L 5.15.0-next-20211112+ #88
+[ 594.371891] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014
+[ 594.373604] Workqueue: events_unbound io_ring_exit_work
+[ 594.374303] RIP: 0010:_raw_spin_unlock_irqrestore+0x33/0x50
+[ 594.375037] Code: 48 83 c7 18 53 48 89 f3 48 8b 74 24 10 e8 55 f5 55 fd 48 89 ef e8 ed a7 56 fd 80 e7 02 74 06 e8 43 13 7b fd fb bf 01 00 00 00 <e8> f8 78 474
+[ 594.377433] RSP: 0018:ffff888101587a70 EFLAGS: 00000202
+[ 594.378120] RAX: 0000000024030f0d RBX: 0000000000000246 RCX: 1ffffffff2f09106
+[ 594.379053] RDX: 0000000000000000 RSI: ffffffff9449f0e0 RDI: 0000000000000001
+[ 594.379991] RBP: ffffffff9586cdc0 R08: 0000000000000001 R09: fffffbfff2effcab
+[ 594.380923] R10: ffffffff977fe557 R11: fffffbfff2effcaa R12: ffff8881b8f3def0
+[ 594.381858] R13: 0000000000000246 R14: ffff888153a8b070 R15: 0000000000000000
+[ 594.382787] FS: 0000000000000000(0000) GS:ffff888399c00000(0000) knlGS:0000000000000000
+[ 594.383851] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
+[ 594.384602] CR2: 00007fcbe71d2000 CR3: 00000000b4216000 CR4: 00000000000006e0
+[ 594.385540] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
+[ 594.386474] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
+[ 594.387403] Call Trace:
+[ 594.387738] <TASK>
+[ 594.388042] find_and_remove_object+0x118/0x160
+[ 594.389321] delete_object_full+0xc/0x20
+[ 594.389852] kfree+0x193/0x470
+[ 594.390275] __io_remove_buffers.part.0+0xed/0x147
+[ 594.390931] io_ring_ctx_free+0x342/0x6a2
+[ 594.392159] io_ring_exit_work+0x41e/0x486
+[ 594.396419] process_one_work+0x906/0x15a0
+[ 594.399185] worker_thread+0x8b/0xd80
+[ 594.400259] kthread+0x3bf/0x4a0
+[ 594.401847] ret_from_fork+0x22/0x30
+[ 594.402343] </TASK>
+
+Message from syslogd@localhost at Nov 13 09:09:54 ...
+kernel:watchdog: BUG: soft lockup - CPU#2 stuck for 26s! [kworker/u32:5:108]
+[ 596.793660] __io_remove_buffers: [2099199]start ctx=0xffff8881067bf000 bgid=65533 buf=0xffff8881fefe1680
+
+We can reproduce this issue by follow syzkaller log:
+r0 = syz_io_uring_setup(0x401, &(0x7f0000000300), &(0x7f0000003000/0x2000)=nil, &(0x7f0000ff8000/0x4000)=nil, &(0x7f0000000280)=<r1=>0x0, &(0x7f0000000380)=<r2=>0x0)
+sendmsg$ETHTOOL_MSG_FEATURES_SET(0xffffffffffffffff, &(0x7f0000003080)={0x0, 0x0, &(0x7f0000003040)={&(0x7f0000000040)=ANY=[], 0x18}}, 0x0)
+syz_io_uring_submit(r1, r2, &(0x7f0000000240)=@IORING_OP_PROVIDE_BUFFERS={0x1f, 0x5, 0x0, 0x401, 0x1, 0x0, 0x100, 0x0, 0x1, {0xfffd}}, 0x0)
+io_uring_enter(r0, 0x3a2d, 0x0, 0x0, 0x0, 0x0)
+
+The reason above issue is 'buf->list' has 2,100,000 nodes, occupied cpu lead
+to soft lockup.
+To solve this issue, we need add schedule point when do while loop in
+'__io_remove_buffers'.
+After add schedule point we do regression, get follow data.
+[ 240.141864] __io_remove_buffers: [1]start ctx=0xffff888170603000 bgid=65533 buf=0xffff8881116fcb00
+[ 268.408260] __io_remove_buffers: [1]start ctx=0xffff8881b92d2000 bgid=65533 buf=0xffff888130c83180
+[ 275.899234] __io_remove_buffers: [2099199]start ctx=0xffff888170603000 bgid=65533 buf=0xffff8881116fcb00
+[ 296.741404] __io_remove_buffers: [1]start ctx=0xffff8881b659c000 bgid=65533 buf=0xffff8881010fe380
+[ 305.090059] __io_remove_buffers: [2099199]start ctx=0xffff8881b92d2000 bgid=65533 buf=0xffff888130c83180
+[ 325.415746] __io_remove_buffers: [1]start ctx=0xffff8881b92d1000 bgid=65533 buf=0xffff8881a17d8f00
+[ 333.160318] __io_remove_buffers: [2099199]start ctx=0xffff8881b659c000 bgid=65533 buf=0xffff8881010fe380
+...
+
+Fixes:8bab4c09f24e("io_uring: allow conditional reschedule for intensive iterators")
+Signed-off-by: Ye Bin <yebin10@huawei.com>
+Link: https://lore.kernel.org/r/20211122024737.2198530-1-yebin10@huawei.com
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/io_uring.c | 5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/fs/io_uring.c
++++ b/fs/io_uring.c
+@@ -4343,6 +4343,7 @@ static int __io_remove_buffers(struct io
+ kfree(nxt);
+ if (++i == nbufs)
+ return i;
++ cond_resched();
+ }
+ i++;
+ kfree(buf);
+@@ -9249,10 +9250,8 @@ static void io_destroy_buffers(struct io
+ struct io_buffer *buf;
+ unsigned long index;
+
+- xa_for_each(&ctx->io_buffers, index, buf) {
++ xa_for_each(&ctx->io_buffers, index, buf)
+ __io_remove_buffers(ctx, buf, index, -1U);
+- cond_resched();
+- }
+ }
+
+ static void io_req_cache_free(struct list_head *list)
ksmbd-fix-an-error-handling-path-in-smb2_sess_setup.patch
tracing-check-pid-filtering-when-creating-events.patch
cifs-nosharesock-should-be-set-on-new-server.patch
+io_uring-fix-soft-lockup-when-call-__io_remove_buffers.patch
+firmware-arm_scmi-fix-type-error-assignment-in-voltage-protocol.patch
+firmware-arm_scmi-fix-type-error-in-sensor-protocol.patch
+docs-accounting-update-delay-accounting.rst-reference.patch
+blk-mq-cancel-blk-mq-dispatch-work-in-both-blk_cleanup_queue-and-disk_release.patch
+block-avoid-to-quiesce-queue-in-elevator_init_mq.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
