On 2020-10-28 15:12:51 [+0100], To linux-block@xxxxxxxxxxxxxxx wrote:
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -667,14 +632,21 @@ bool blk_mq_complete_request_remote(struct request *rq)
> return false;
>
> if (blk_mq_complete_need_ipi(rq)) {
…
> } else {
> if (rq->q->nr_hw_queues > 1)
> return false;
> - blk_mq_trigger_softirq(rq);
> + cpu_list = this_cpu_ptr(&blk_cpu_done);
> + if (llist_add(&rq->ipi_list, cpu_list))
> + raise_softirq(BLOCK_SOFTIRQ);
> }
>
> return true;
So Mike posted this:
| BUG: using smp_processor_id() in preemptible [00000000] code: usb-storage/841
| caller is blk_mq_complete_request_remote.part.0+0xa2/0x120
| CPU: 0 PID: 841 Comm: usb-storage Not tainted 5.10.0-rc1+ #61
| Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-1 04/01/2014
| Call Trace:
| dump_stack+0x77/0x97
| check_preemption_disabled+0xbe/0xc0
| blk_mq_complete_request_remote.part.0+0xa2/0x120
| blk_mq_complete_request+0x2e/0x40
| usb_stor_control_thread+0x29a/0x300
| kthread+0x14b/0x170
| ret_from_fork+0x22/0x30
This comes from this_cpu_ptr() because usb_stor_control_thread() runs
with enabled preemption.
Adding preempt_disable() around it will make the warning go away but
will wake the ksoftirqd (this happens now, too).
Adding local_bh_disable() around it would perform the completion
immediately (instead of waking kssoftirqd) but local_bh_enable() feels
slightly more expensive.
Are there many drivers completing the SCSI requests in preemtible
context? In this case it would be more efficient to complete the request
directly (usb_stor_control_thread() goes to sleep after that anyway and
there is only one request at a time).
Sebastian
