Boaz Harrosh wrote:
Also timeout failure can still occur after scsi_request_fn unlock the
host_lock and before scsi_dispatch_cmd re-lock it.
This was exactly my intention, to do all the things that can fail and the unlocking
then relocking before we start the request. And leave no failing possibility and lock
released between the start of the request and the dispatching. I think it would be wroth it.
But it's your call
Boaz
How do you leave no failing possibility? As long as there is unlock and
then relocking, it is unsafe since timeout could occur right between.
Unless you meant hold the lock entirely but your patch didn't show.
e.g. the following scsi_request_fn() cmd could be a corrupt point
already. I thought about removing this unlock call, but
scsi_dispatch_cmd has this sleep call need to hack around.
/*
* XXX(hch): This is rather suboptimal, scsi_dispatch_cmd will
* take the lock again.
*/
spin_unlock_irq(shost->host_lock);
scsi_init_cmd_errh(cmd);
My other wish is to delay the start of timer until command is queued,
but that has to change upper layer blk_start_request and might change
entire block layer algorithm, too much impact on the other driver that
use it.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
