| Message ID | 1515408716-102111-1-git-send-email-hare@suse.de (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
On Mon, Jan 08, 2018 at 11:51:56AM +0100, Hannes Reinecke wrote: > The abort handler might be racing with command completion, so the > task might already be NULL by the time the abort handler is called. But without taking dev_done_lock (or using cmpxchg) what prevents use from still hitting this, although in a more narrow window?
On 01/08/2018 12:23 PM, Christoph Hellwig wrote: > On Mon, Jan 08, 2018 at 11:51:56AM +0100, Hannes Reinecke wrote: >> The abort handler might be racing with command completion, so the >> task might already be NULL by the time the abort handler is called. > > But without taking dev_done_lock (or using cmpxchg) what prevents > use from still hitting this, although in a more narrow window? > Good point. Will be updating the patch. Cheers, Hannes
diff --git a/drivers/scsi/libsas/sas_scsi_host.c b/drivers/scsi/libsas/sas_scsi_host.c index 58476b7..ae2ae3c 100644 --- a/drivers/scsi/libsas/sas_scsi_host.c +++ b/drivers/scsi/libsas/sas_scsi_host.c @@ -486,7 +486,7 @@ static int sas_queue_reset(struct domain_device *dev, int reset_type, int sas_eh_abort_handler(struct scsi_cmnd *cmd) { - int res; + int res = TMF_RESP_FUNC_COMPLETE; struct sas_task *task = TO_SAS_TASK(cmd); struct Scsi_Host *host = cmd->device->host; struct sas_internal *i = to_sas_internal(host->transportt); @@ -494,7 +494,8 @@ int sas_eh_abort_handler(struct scsi_cmnd *cmd) if (!i->dft->lldd_abort_task) return FAILED; - res = i->dft->lldd_abort_task(task); + if (task) + res = i->dft->lldd_abort_task(task); if (res == TMF_RESP_FUNC_SUCC || res == TMF_RESP_FUNC_COMPLETE) return SUCCESS;
The abort handler might be racing with command completion, so the task might already be NULL by the time the abort handler is called. Signed-off-by: Hannes Reinecke <hare@suse.com> --- drivers/scsi/libsas/sas_scsi_host.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)