From: Ming Lei <ming.lei@redhat.com>
To: Nilay Shroff <nilay@linux.ibm.com>
Cc: "Jens Axboe" <axboe@kernel.dk>,
linux-block@vger.kernel.org,
"Shinichiro Kawasaki" <shinichiro.kawasaki@wdc.com>,
"Thomas Hellström" <thomas.hellstrom@linux.intel.com>,
"Christoph Hellwig" <hch@lst.de>
Subject: Re: [PATCH V2 07/20] block: prevent adding/deleting disk during updating nr_hw_queues
Date: Mon, 21 Apr 2025 10:39:24 +0800 [thread overview]
Message-ID: <aAWv3NPtNIKKvJZc@fedora> (raw)
In-Reply-To: <094c312a-38ec-4c5b-9db3-2269c37de36a@linux.ibm.com>
On Sat, Apr 19, 2025 at 04:50:15PM +0530, Nilay Shroff wrote:
>
>
> On 4/18/25 10:06 PM, Ming Lei wrote:
> > Both adding/deleting disk code are reader of `nr_hw_queues`, so we can't
> > allow them in-progress when updating nr_hw_queues, kernel panic and
> > kasan has been reported in [1].
> >
> > Prevent adding/deleting disk during updating nr_hw_queues by setting
> > set->updating_nr_hwq, and use SRCU to fail & retry to add/delete disk.
> >
> > This way avoids lot of trouble.
> >
> > Reported-by: Nilay Shroff <nilay@linux.ibm.com>
> > Closes: https://lore.kernel.org/linux-block/a5896cdb-a59a-4a37-9f99-20522f5d2987@linux.ibm.com/
> > Signed-off-by: Ming Lei <ming.lei@redhat.com>
> > ---
> [...]
> [...]
> >
> > +static int retry_on_updating_nr_hwq(struct gendisk_data *data,
> > + int (*cb)(struct gendisk_data *data))
> > +{
> > + struct gendisk *disk = data->disk;
> > + struct blk_mq_tag_set *set;
> > +
> > + if (!queue_is_mq(disk->queue))
> > + return cb(data);
> > +
> > + set = disk->queue->tag_set;
> > + do {
> > + int idx, ret;
> > +
> > + idx = srcu_read_lock(&set->update_nr_hwq_srcu);
> > + if (set->updating_nr_hwq) {
> > + srcu_read_unlock(&set->update_nr_hwq_srcu, idx);
> > + goto wait;
> > + }
> > + ret = cb(data);
> > + srcu_read_unlock(&set->update_nr_hwq_srcu, idx);
> > + return ret;
> > + wait:
> > + wait_event_interruptible(set->update_nr_hwq_wq,
> > + !set->updating_nr_hwq);
> > + } while (true);
> > +}
> > +
> Yes using srcu with wait event would fix this. However after looking through
> changes it seems to me that the current changes are now modeled as below:
>
> - Writer(blk_mq_update_nr_hw_queues) must wait until all readers are done
> (or prior SRCU read-side critical-section complete)
> - Readers (add/del disk) must wait until a writer(blk_mq_update_nr_hw_queues)
> finishes
>
> And IMO, this behavior is best modeled with a reader-writer lock, rather than
> (S)RCU.
>
> In my view, RCU is optimized for read-heavy workloads with:
> - Non-blocking readers
srcu allows blocking reader
> - Deferred updates by writers
> - Writers don’t block readers and readers don’t block writers.
>
> So I believe the simpler choice shall be using reader-writer lock instead of srcu.
> With reader-writer lock we should be also able to get away with implementing wait
> queue for add/del disk. Moreover, the reader-writer lock shall also work well with
> the another reader elv_iosched_store.
Basically I agree with you that rwsem(instead of rwlock) should match with
this case in theory, but I feel that rwsem is stronger than srcu from lock
viewpoint, and we will add new dependency if rwsem is held inside
->store(), such as the following splat.
[ 93.214889] ======================================================
[ 93.219162] scsi 10:0:0:0: Direct-Access Linux scsi_debug 0191 PQ: 0 ANSI: 7
[ 93.219549] WARNING: possible circular locking dependency detected
[ 93.219557] 6.15.0-rc2_ublk+ #536 Not tainted
[ 93.219565] ------------------------------------------------------
[ 93.219568] check/1690 is trying to acquire lock:
[ 93.222730] sd 9:0:0:0: [sdc] Synchronizing SCSI cache
[ 93.223139] ffff8882ad849598
[ 93.224074] scsi 10:0:0:0: Power-on or device reset occurred
[ 93.227331] scsi 9:0:0:0: Direct-Access Linux scsi_debug 0191 PQ: 0 ANSI: 7
[ 93.227581] (kn->active#103){++++}-{0:0}, at: __kernfs_remove+0x213/0x680
[ 93.231428] scsi 9:0:0:0: Power-on or device reset occurred
[ 93.231890]
but task is already holding lock:
[ 93.231897] ffff88828ef358a0 (&q->q_usage_counter(queue)#14
[ 93.232621] sd 10:0:0:0: Attached scsi generic sg3 type 0
[ 93.234640] sd 10:0:0:0: [sdc] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB)
[ 93.235975] ){++++}-{0:0}, at: del_gendisk+0x186/0x250
[ 93.238123] sd 10:0:0:0: [sdc] Write Protect is off
[ 93.239546]
which lock already depends on the new lock.
[ 93.239552]
the existing dependency chain (in reverse order) is:
[ 93.239556]
-> #4 (&q->q_usage_counter(queue)
[ 93.240114] sd 9:0:0:0: Attached scsi generic sg3 type 0
[ 93.240963] sd 10:0:0:0: [sdc] Mode Sense: 00 00 00 00
[ 93.241757] sd 9:0:0:0: [sde] 16384 512-byte logical blocks: (8.39 MB/8.00 MiB)
[ 93.242387] #14){++++}-{0:0}:
[ 93.242404] blk_queue_enter+0x4c9/0x640
[ 93.242916] sd 9:0:0:0: [sde] Write Protect is off
[ 93.242948] sd 9:0:0:0: [sde] Mode Sense: 73 00 10 08
[ 93.243028] sd 9:0:0:0: [sde] Asking for cache data failed
[ 93.243057] sd 9:0:0:0: [sde] Assuming drive cache: write through
[ 93.243120] sd 9:0:0:0: [sde] Unexpected: RSCS has been set and the permanent stream count is 0
[ 93.243255] sd 9:0:0:0: [sde] Preferred minimum I/O size 512 bytes
[ 93.243284] sd 9:0:0:0: [sde] Optimal transfer size 524288 bytes
[ 93.243568] sd 10:0:0:0: [sdc] Asking for cache data failed
[ 93.244771] blk_mq_alloc_request+0x4ae/0x8d0
[ 93.244786] scsi_execute_cmd+0x196/0xcf0
[ 93.246604] sd 10:0:0:0: [sdc] Assuming drive cache: write through
[ 93.247875] read_capacity_16+0x1cf/0xbf0
[ 93.247891] sd_revalidate_disk.isra.0+0x15c0/0x8f50
[ 93.249239] sd 10:0:0:0: [sdc] Unexpected: RSCS has been set and the permanent stream count is 0
[ 93.251084] sd_probe+0x815/0xf20
[ 93.251098] really_probe+0x1e0/0x930
[ 93.252235] sd 10:0:0:0: [sdc] Preferred minimum I/O size 512 bytes
[ 93.253608] __driver_probe_device+0x18c/0x3d0
[ 93.253623] driver_probe_device+0x4a/0x120
[ 93.253633] __device_attach_driver+0x162/0x270
[ 93.253643] bus_for_each_drv+0x114/0x1a0
[ 93.255593] sd 10:0:0:0: [sdc] Optimal transfer size 524288 bytes
[ 93.256874] __device_attach_async_helper+0x19e/0x240
[ 93.362362] async_run_entry_fn+0x97/0x4f0
[ 93.364343] process_one_work+0x841/0x17a0
[ 93.366439] worker_thread+0x6e8/0x1270
[ 93.369068] kthread+0x388/0x750
[ 93.371762] ret_from_fork+0x31/0x70
[ 93.374588] ret_from_fork_asm+0x1a/0x30
[ 93.377490]
-> #3 (&q->limits_lock){+.+.}-{4:4}:
[ 93.381214] __mutex_lock+0x192/0x1960
[ 93.383220] get_sectorsize+0x234/0x5f0
[ 93.384945] sr_block_open+0x1a9/0x220
[ 93.386895] blkdev_get_whole+0x8f/0x200
[ 93.388922] bdev_open+0x223/0xc10
[ 93.390776] blkdev_open+0x1f3/0x350
[ 93.392704] do_dentry_open+0x491/0x1820
[ 93.394676] vfs_open+0x82/0x350
[ 93.396370] path_openat+0x1b0c/0x2b10
[ 93.398150] do_filp_open+0x1e7/0x430
[ 93.400494] do_sys_openat2+0xed/0x180
[ 93.403129] __x64_sys_openat+0x122/0x1e0
[ 93.405846] do_syscall_64+0x95/0x180
[ 93.408486] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 93.411165]
-> #2 (&disk->open_mutex){+.+.}-{4:4}:
[ 93.414296] __mutex_lock+0x192/0x1960
[ 93.415744] bdev_open+0x339/0xc10
[ 93.417148] bdev_file_open_by_dev+0xc6/0x140
[ 93.418669] disk_scan_partitions+0x190/0x280
[ 93.420188] __add_disk_fwnode+0xdfe/0x1140
[ 93.421708] device_add_disk+0x184/0x270
[ 93.423162] nvme_alloc_ns+0x16f5/0x3580
[ 93.424625] nvme_scan_ns+0x628/0x7f0
[ 93.425974] async_run_entry_fn+0x97/0x4f0
[ 93.427424] process_one_work+0x841/0x17a0
[ 93.428876] worker_thread+0x6e8/0x1270
[ 93.430336] kthread+0x388/0x750
[ 93.431760] ret_from_fork+0x31/0x70
[ 93.433186] ret_from_fork_asm+0x1a/0x30
[ 93.434667]
-> #1 (&set->update_nr_hwq_lock){.+.+}-{4:4}:
[ 93.437156] down_read_interruptible+0x92/0x490
[ 93.438774] elevator_change+0x1a8/0x210
[ 93.440281] elv_iosched_store+0x14d/0x1f0
[ 93.441928] queue_attr_store+0x235/0x2f0
[ 93.443469] kernfs_fop_write_iter+0x359/0x530
[ 93.445074] vfs_write+0x5fb/0x1130
[ 93.446440] ksys_write+0xf9/0x1c0
[ 93.447714] do_syscall_64+0x95/0x180
[ 93.449042] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 93.450585]
-> #0 (kn->active#103){++++}-{0:0}:
[ 93.452761] __lock_acquire+0x1459/0x2200
[ 93.454081] lock_acquire+0x165/0x310
[ 93.455378] kernfs_drain+0x3a8/0x460
[ 93.456736] __kernfs_remove+0x213/0x680
[ 93.458162] kernfs_remove_by_name_ns+0x9c/0x110
[ 93.459707] remove_files+0x8c/0x1a0
[ 93.461066] sysfs_remove_group+0x7b/0x160
[ 93.462494] sysfs_remove_groups+0x53/0xa0
[ 93.463916] __kobject_del+0x7d/0x1d0
[ 93.465242] kobject_del+0x35/0x50
[ 93.466568] blk_unregister_queue+0x154/0x2c0
[ 93.468022] __del_gendisk+0x4d1/0xa10
[ 93.469391] del_gendisk+0x186/0x250
[ 93.470757] sd_remove+0x89/0x130
[ 93.472093] device_release_driver_internal+0x379/0x540
[ 93.473726] bus_remove_device+0x1f5/0x3f0
[ 93.475198] device_del+0x33c/0x8d0
[ 93.476458] __scsi_remove_device+0x276/0x340
[ 93.477877] sdev_store_delete+0x87/0x120
[ 93.479288] kernfs_fop_write_iter+0x359/0x530
[ 93.480710] vfs_write+0x5fb/0x1130
[ 93.481986] ksys_write+0xf9/0x1c0
[ 93.483267] do_syscall_64+0x95/0x180
[ 93.484595] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 93.486120]
other info that might help us debug this:
[ 93.489456] Chain exists of:
kn->active#103 --> &q->limits_lock --> &q->q_usage_counter(queue)#14
[ 93.493238] Possible unsafe locking scenario:
[ 93.495533] CPU0 CPU1
[ 93.496993] ---- ----
[ 93.498399] lock(&q->q_usage_counter(queue)#14);
[ 93.499859] lock(&q->limits_lock);
[ 93.501504] lock(&q->q_usage_counter(queue)#14);
[ 93.503463] lock(kn->active#103);
[ 93.504830]
*** DEADLOCK ***
[ 93.507934] 6 locks held by check/1690:
[ 93.509293] #0: ffff88811032c420 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1c0
[ 93.511216] #1: ffff888115cbb088 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0x21d/0x530
[ 93.513380] #2: ffff888126a140e0 (&shost->scan_mutex){+.+.}-{4:4}, at: sdev_store_delete+0x7f/0x120
[ 93.515654] #3: ffff8882a1b4e380 (&dev->mutex){....}-{4:4}, at: device_release_driver_internal+0x91/0x540
[ 93.517859] #4: ffff888126a14388 (&set->update_nr_hwq_lock){.+.+}-{4:4}, at: del_gendisk+0x17c/0x250
[ 93.520267] #5: ffff88828ef358a0 (&q->q_usage_counter(queue)#14){++++}-{0:0}, at: del_gendisk+0x186/0x250
[ 93.522559]
stack backtrace:
[ 93.524777] CPU: 2 UID: 0 PID: 1690 Comm: check Not tainted 6.15.0-rc2_ublk+ #536 PREEMPT(voluntary)
[ 93.524785] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39 04/01/2014
[ 93.524789] Call Trace:
[ 93.524794] <TASK>
[ 93.524799] dump_stack_lvl+0x93/0xf0
[ 93.524810] print_circular_bug+0x275/0x340
[ 93.524820] check_noncircular+0x146/0x160
[ 93.524831] __lock_acquire+0x1459/0x2200
[ 93.524842] lock_acquire+0x165/0x310
[ 93.524849] ? __kernfs_remove+0x213/0x680
[ 93.524857] ? up_write+0x19e/0x500
[ 93.524864] kernfs_drain+0x3a8/0x460
[ 93.524870] ? __kernfs_remove+0x213/0x680
[ 93.524878] ? __pfx_kernfs_drain+0x10/0x10
[ 93.524884] ? find_held_lock+0x2b/0x80
[ 93.524889] ? kernfs_root+0xb0/0x1c0
[ 93.524900] __kernfs_remove+0x213/0x680
[ 93.524906] ? kernfs_find_ns+0x192/0x390
[ 93.524914] kernfs_remove_by_name_ns+0x9c/0x110
[ 93.524923] remove_files+0x8c/0x1a0
[ 93.524930] sysfs_remove_group+0x7b/0x160
[ 93.524937] sysfs_remove_groups+0x53/0xa0
[ 93.524945] __kobject_del+0x7d/0x1d0
[ 93.524953] kobject_del+0x35/0x50
[ 93.524960] blk_unregister_queue+0x154/0x2c0
[ 93.524968] __del_gendisk+0x4d1/0xa10
[ 93.524978] ? __pfx___del_gendisk+0x10/0x10
[ 93.524986] ? kobject_put+0x61/0x4b0
[ 93.524995] del_gendisk+0x186/0x250
[ 93.525019] ? __pfx_del_gendisk+0x10/0x10
[ 93.525029] ? __pm_runtime_resume+0x79/0x100
[ 93.525048] sd_remove+0x89/0x130
[ 93.525059] device_release_driver_internal+0x379/0x540
[ 93.525068] ? kobject_put+0x61/0x4b0
[ 93.525076] bus_remove_device+0x1f5/0x3f0
[ 93.525085] device_del+0x33c/0x8d0
[ 93.525093] ? attribute_container_device_trigger+0x183/0x1f0
[ 93.525099] ? __pfx_device_del+0x10/0x10
[ 93.525106] ? __pfx_attribute_container_device_trigger+0x10/0x10
[ 93.525115] __scsi_remove_device+0x276/0x340
[ 93.525122] sdev_store_delete+0x87/0x120
[ 93.525128] kernfs_fop_write_iter+0x359/0x530
[ 93.525138] vfs_write+0x5fb/0x1130
[ 93.525147] ? __pfx_vfs_write+0x10/0x10
[ 93.525158] ? lock_acquire+0x165/0x310
[ 93.525165] ? nohz_balance_exit_idle.part.0+0xe2/0x330
[ 93.525175] ksys_write+0xf9/0x1c0
[ 93.525182] ? __pfx_ksys_write+0x10/0x10
[ 93.525188] ? __pfx_run_posix_cpu_timers+0x10/0x10
[ 93.525198] do_syscall_64+0x95/0x180
[ 93.525206] ? __lock_acquire+0x432/0x2200
[ 93.525219] ? __lock_acquire+0x432/0x2200
[ 93.525229] ? lock_acquire+0x165/0x310
[ 93.525236] ? ktime_get+0x32/0x150
[ 93.525243] ? find_held_lock+0x2b/0x80
[ 93.525248] ? ktime_get+0x32/0x150
[ 93.525257] ? seqcount_lockdep_reader_access.constprop.0+0x4b/0xb0
[ 93.525264] ? kvm_sched_clock_read+0x11/0x20
[ 93.525270] ? sched_clock+0x10/0x30
[ 93.525277] ? sched_clock_cpu+0x6c/0x4c0
[ 93.525286] ? __pfx_sched_clock_cpu+0x10/0x10
[ 93.525293] ? hrtimer_interrupt+0x363/0x870
[ 93.525301] ? irqtime_account_irq+0x51/0x200
[ 93.525310] ? irqentry_exit_to_user_mode+0x90/0x280
[ 93.525318] ? clear_bhb_loop+0x35/0x90
[ 93.525324] ? clear_bhb_loop+0x35/0x90
[ 93.525329] ? clear_bhb_loop+0x35/0x90
[ 93.525335] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 93.525341] RIP: 0033:0x7f6a158fb174
[ 93.525364] Code: 89 02 48 c7 c0 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 80 3d 6d b4 0d 00 00 74 13 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89
[ 93.525369] RSP: 002b:00007fff65c97158 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
[ 93.525376] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f6a158fb174
[ 93.525381] RDX: 0000000000000002 RSI: 0000563b4b680130 RDI: 0000000000000001
[ 93.525384] RBP: 00007fff65c97180 R08: 0000000000000073 R09: 0000000000000001
[ 93.525387] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000002
[ 93.525395] R13: 0000563b4b680130 R14: 00007f6a159cf780 R15: 0000000000000002
[ 93.525407] </TASK>
[ 93.657609] sd 11:0:0:0: [sdd] Synchronizing SCSI cache
Thanks,
Ming
next prev parent reply other threads:[~2025-04-21 2:39 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-18 16:36 [PATCH V2 00/20] block: unify elevator changing and fix lockdep warning Ming Lei
2025-04-18 16:36 ` [PATCH V2 01/20] block: move blk_mq_add_queue_tag_set() after blk_mq_map_swqueue() Ming Lei
2025-04-19 8:57 ` Yu Kuai
2025-04-19 10:25 ` Nilay Shroff
2025-04-21 12:31 ` Christoph Hellwig
2025-04-22 6:00 ` Hannes Reinecke
2025-04-18 16:36 ` [PATCH V2 02/20] block: move ELEVATOR_FLAG_DISABLE_WBT as request queue flag Ming Lei
2025-04-19 8:59 ` Yu Kuai
2025-04-19 14:52 ` Nilay Shroff
2025-04-21 12:33 ` Christoph Hellwig
2025-04-22 6:01 ` Hannes Reinecke
2025-04-18 16:36 ` [PATCH V2 03/20] block: don't call freeze queue in elevator_switch() and elevator_disable() Ming Lei
2025-04-19 9:01 ` Yu Kuai
2025-04-21 12:34 ` Christoph Hellwig
2025-04-22 4:00 ` Ming Lei
2025-04-22 7:00 ` Christoph Hellwig
2025-04-22 6:02 ` Hannes Reinecke
2025-04-18 16:36 ` [PATCH V2 04/20] block: add two helpers for registering/un-registering sched debugfs Ming Lei
2025-04-19 9:18 ` Yu Kuai
2025-04-19 10:27 ` Nilay Shroff
2025-04-21 12:36 ` Christoph Hellwig
2025-04-22 6:04 ` Hannes Reinecke
2025-04-18 16:36 ` [PATCH V2 05/20] block: move sched debugfs register into elvevator_register_queue Ming Lei
2025-04-19 9:28 ` Yu Kuai
2025-04-19 10:28 ` Nilay Shroff
2025-04-21 12:37 ` Christoph Hellwig
2025-04-22 6:06 ` Hannes Reinecke
2025-04-18 16:36 ` [PATCH V2 06/20] block: add & pass 'struct gendisk_data' for retrying add/del disk in updating nr_hw_queues Ming Lei
2025-04-18 16:36 ` [PATCH V2 07/20] block: prevent adding/deleting disk during " Ming Lei
2025-04-19 11:20 ` Nilay Shroff
2025-04-21 2:39 ` Ming Lei [this message]
2025-04-22 7:04 ` Christoph Hellwig
2025-04-22 9:29 ` Ming Lei
2025-04-22 10:26 ` Nilay Shroff
2025-04-18 16:36 ` [PATCH V2 08/20] block: don't allow to switch elevator if updating nr_hw_queues is in-progress Ming Lei
2025-04-19 11:22 ` Nilay Shroff
2025-04-18 16:36 ` [PATCH V2 09/20] block: simplify elevator rebuild for updating nr_hw_queues Ming Lei
2025-04-19 11:25 ` Nilay Shroff
2025-04-18 16:36 ` [PATCH V2 10/20] block: add helper of elevator_change() Ming Lei
2025-04-18 16:36 ` [PATCH V2 11/20] block: move blk_unregister_queue() & device_del() after freeze wait Ming Lei
2025-04-19 12:38 ` Nilay Shroff
2025-04-22 10:50 ` Ming Lei
2025-04-18 16:36 ` [PATCH V2 12/20] block: add `struct elv_change_ctx` for unifying elevator_change Ming Lei
2025-04-19 12:40 ` Nilay Shroff
2025-04-22 7:07 ` Christoph Hellwig
2025-04-22 8:36 ` Ming Lei
2025-04-23 7:10 ` Christoph Hellwig
2025-04-18 16:36 ` [PATCH V2 13/20] block: unifying elevator change Ming Lei
2025-04-19 13:26 ` Nilay Shroff
2025-04-24 9:02 ` Ming Lei
2025-04-18 16:36 ` [PATCH V2 14/20] block: pass elevator_queue to elv_register_queue & unregister_queue Ming Lei
2025-04-19 13:28 ` Nilay Shroff
2025-04-18 16:36 ` [PATCH V2 15/20] block: fail to show/store elevator sysfs attribute if elevator is dying Ming Lei
2025-04-19 13:45 ` Nilay Shroff
2025-04-18 16:36 ` [PATCH V2 16/20] block: move elv_register[unregister]_queue out of elevator_lock Ming Lei
2025-04-19 13:55 ` Nilay Shroff
2025-04-22 10:53 ` Ming Lei
2025-04-22 11:06 ` Nilay Shroff
2025-04-22 11:14 ` Ming Lei
2025-04-18 16:36 ` [PATCH V2 17/20] block: move debugfs/sysfs register out of freezing queue Ming Lei
2025-04-19 13:57 ` Nilay Shroff
2025-04-18 16:36 ` [PATCH V2 18/20] block: remove several ->elevator_lock Ming Lei
2025-04-19 14:17 ` Nilay Shroff
2025-04-18 16:37 ` [PATCH V2 19/20] block: move hctx cpuhp add/del out of queue freezing Ming Lei
2025-04-19 14:20 ` Nilay Shroff
2025-04-18 16:37 ` [PATCH V2 20/20] block: move wbt_enable_default() out of queue freezing from sched ->exit() Ming Lei
2025-04-19 14:39 ` Nilay Shroff
2025-04-21 7:27 ` Ming Lei
2025-04-22 6:14 ` Nilay Shroff
2025-04-22 8:13 ` Ming Lei
2025-04-22 9:27 ` Nilay Shroff
2025-04-22 9:33 ` Ming Lei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aAWv3NPtNIKKvJZc@fedora \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=linux-block@vger.kernel.org \
--cc=nilay@linux.ibm.com \
--cc=shinichiro.kawasaki@wdc.com \
--cc=thomas.hellstrom@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.