Let's check a scenario:
1. blk_delay_queue(q, SCSI_QUEUE_DELAY);
2. blk_run_queue_async();
the second one will became a noop, because q->delay_work already has
WORK_STRUCT_PENDING_BIT set, so the delayed work will still run after
SCSI_QUEUE_DELAY. But blk_run_queue_async actually hopes the delayed
work runs immediately.
Signed-off-by: Shaohua Li <[email protected]>
---
block/blk-core.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: linux/block/blk-core.c
===================================================================
--- linux.orig/block/blk-core.c 2011-05-18 16:17:54.000000000 +0800
+++ linux/block/blk-core.c 2011-05-18 16:29:38.000000000 +0800
@@ -316,8 +316,10 @@ EXPORT_SYMBOL(__blk_run_queue);
*/
void blk_run_queue_async(struct request_queue *q)
{
- if (likely(!blk_queue_stopped(q)))
+ if (likely(!blk_queue_stopped(q))) {
+ __cancel_delayed_work(&q->delay_work);
queue_delayed_work(kblockd_workqueue, &q->delay_work, 0);
+ }
}
EXPORT_SYMBOL(blk_run_queue_async);
On 2011-05-18 10:42, Shaohua Li wrote:
> Let's check a scenario:
> 1. blk_delay_queue(q, SCSI_QUEUE_DELAY);
> 2. blk_run_queue_async();
> the second one will became a noop, because q->delay_work already has
> WORK_STRUCT_PENDING_BIT set, so the delayed work will still run after
> SCSI_QUEUE_DELAY. But blk_run_queue_async actually hopes the delayed
> work runs immediately.
Good catch. I wonder if it wouldn't be better to "fix"
queue_delayed_work() instead. If the time passed in is before the
scheduled event, adjust the timeout.
But as a 2.6.39 fix, this is good, will queue up.
--
Jens Axboe