On 9/11/25 1:15 AM, John Garry wrote:
this can race with a call to scsi_change_queue_depth() (which may free
sdev->budget_map.map), right?
scsi_change_queue_depth() does not seem to do any queue freezing.
Hi John,
Are there any SCSI devices left about which we care and for which queue
depth tracking is important?
scsi_change_queue_depth() can be called from interrupt context as
follows:
LLD completion interrupt
scsi_done()
scsi_done_internal()
blk_mq_complete_request()
scsi_complete()
scsi_decide_disposition()
scsi_handle_queue_ramp_up()
scsi_change_queue_depth()
Freezing a request queue requires thread context. Hence, the queue ramp
up queue depth increase would have to happen asynchronously, e.g. via
queue_work().
Here is another call chain:
scsi_error_handler()
scsi_unjam_host()
scsi_eh_ready_devs()
scsi_eh_host_reset()
scsi_eh_test_devices()
scsi_eh_tur()
scsi_send_eh_cmnd()
scsi_eh_completed_normally()
scsi_handle_queue_full()
scsi_track_queue_full()
scsi_change_queue_depth()
Freezing the request queue probably would result in a deadlock for this
call chain. So also for this call chain, changing the queue depth would
have to happen asynchronously.
Does anyone see any other options than either making
scsi_change_queue_depth() a no-op or making all queue depth changes
asynchronously, except the call from scsi_alloc_sdev()?
Thanks,
Bart.
