From: Jens Axboe Here's a patch to just correct the comment. The md usage is safe because it switches ->make_request_fn before syncing the queue and on second thought it is a bit silly to add freeze/unfreeze functionality that no one will use right now anyways. Alternatively, we could add this functionality to the core so the interface would be /* callers wait for unfreeze */ blk_freeze_queue(q, FREEZE_WAIT); or /* callers are io errored immediately */ blk_freeze_queue(q, FREEZE_END_IO); which would work for both. I'll keep it in mind if such a use becomes attractive, for now I think we should just correct the comment. Signed-off-by: Andrew Morton --- 25-akpm/drivers/block/ll_rw_blk.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff -puN drivers/block/ll_rw_blk.c~blk_sync_queue-updates-update drivers/block/ll_rw_blk.c --- 25/drivers/block/ll_rw_blk.c~blk_sync_queue-updates-update Wed Nov 10 13:39:09 2004 +++ 25-akpm/drivers/block/ll_rw_blk.c Wed Nov 10 13:39:09 2004 @@ -1361,7 +1361,7 @@ void blk_stop_queue(request_queue_t *q) EXPORT_SYMBOL(blk_stop_queue); /** - * blk_sync_queue - cancel any pending callbacks a queue + * blk_sync_queue - cancel any pending callbacks on a queue * @q: the queue * * Description: @@ -1369,7 +1369,9 @@ EXPORT_SYMBOL(blk_stop_queue); * on a queue, such as calling the unplug function after a timeout. * A block device may call blk_sync_queue to ensure that any * such activity is cancelled, thus allowing it to release resources - * the the callbacks might use. + * the the callbacks might use. The caller must already have made sure + * that its ->make_request_fn will not re-add plugging prior to calling + * this function. * */ void blk_sync_queue(struct request_queue *q) _