libsas: dereferencing variable before check
Subsystems (2)
PATCH 1/1 libsas: dereferencing variable before check
The "qc->scsicmd" could be null so I moved the dereference inside the check. This was introduced by 70b25f890: "[SCSI] fix locking around blk_abort_request()"
drivers/scsi/libsas/sas_ata.c +2 -1
@@ -395,12 +395,13 @@ int sas_ata_init_host_and_port(struct domain_device *found_dev,void sas_ata_task_abort (struct sas_task *task) {struct ata_queued_cmd *qc = task->uldd_task; -struct request_queue *q = qc->scsicmd->device->request_queue; +struct request_queue *q;struct completion *waiting;unsigned long flags;/* Bounce SCSI-initiated commands to the SCSI EH */ if (qc->scsicmd) { + q = qc->scsicmd->device->request_queue;spin_lock_irqsave (q->queue_lock, flags);blk_abort_request (qc->scsicmd->request);spin_unlock_irqrestore (q->queue_lock, flags);
Quoted 5 lines · Dan Carpenter
The "
qc->scsicmd" could be null so I moved the dereference inside the check. This was introduced by70b25f890: "[SCSI] fix locking aroundblk_abort_request()"Signed-off-by Dan Carpenter <[email protected]>
Ooh.. right.
Thanks.
Signature · 1 line
tejun
Quoted 7 lines · Tejun Heo
Quoted 4 lines · Dan Carpenter
The "
qc->scsicmd" could be null so I moved the dereference inside the check. This was introduced by70b25f890: "[SCSI] fix locking aroundblk_abort_request()"
Quoted 5 lines
Quoted 1 line
Signed-off-by Dan Carpenter <[email protected]>Ooh.. right.
Asked-by Tejun Heo <[email protected]>
Well, oops, yes. Two patches to fix one bug is a bit overboard, I think, plus some code rearrangement to fix the locality of the problem and ensure it doesn't happen again might be useful. What about this.
James
---
drivers/scsi/libsas/sas_ata.c +3 -2
@@ -395,12 +395,13 @@ int sas_ata_init_host_and_port(struct domain_device *found_dev,void sas_ata_task_abort (struct sas_task *task) {struct ata_queued_cmd *qc = task->uldd_task; -struct request_queue *q = qc->scsicmd->device->request_queue;struct completion *waiting; -unsigned long flags;/* Bounce SCSI-initiated commands to the SCSI EH */ if (qc->scsicmd) { +struct request_queue *q = qc->scsicmd->device->request_queue; +unsigned long flags; +spin_lock_irqsave (q->queue_lock, flags);blk_abort_request (qc->scsicmd->request);spin_unlock_irqrestore (q->queue_lock, flags);
drivers/scsi/libsas/sas_scsi_host.c +8 -8
@@ -1030,8 +1030,6 @@ int __sas_task_abort(struct sas_task *task)void sas_task_abort (struct sas_task *task) {struct scsi_cmnd *sc = task->uldd_task; -struct request_queue *q = sc->device->request_queue; -unsigned long flags;/* Escape for libsas internal commands */ if (!sc) {
@@ -1043,13 +1041,15 @@ void sas_task_abort(struct sas_task *task)if (dev_is_sata (task->dev)) {sas_ata_task_abort (task); -return ; - } + }else { +struct request_queue *q = sc->device->request_queue; +unsigned long flags; -spin_lock_irqsave (q->queue_lock, flags); -blk_abort_request (sc->request); -spin_unlock_irqrestore (q->queue_lock, flags); -scsi_schedule_eh (sc->device->host); +spin_lock_irqsave (q->queue_lock, flags); +blk_abort_request (sc->request); +spin_unlock_irqrestore (q->queue_lock, flags); +scsi_schedule_eh (sc->device->host); + } }int sas_slave_alloc (struct scsi_device *scsi_dev)
Hello,
Quoted 3 lines · James Bottomley
Quoted 3 lines
Ooh.. right.
Asked-by Tejun Heo <[email protected]>
That was my first mail from android and of course I typed Asked instead of Acked. :-)
Quoted 3 lines
Well, oops, yes. Two patches to fix one bug is a bit overboard, I think, plus some code rearrangement to fix the locality of the problem and ensure it doesn't happen again might be useful. What about this.
Yeap, as long as the silly bug is fixed.
Thank you.
Signature · 1 line
tejun
Dan Carpenter
Acked-byQuoted 10 lines · James Bottomley
Quoted 9 lines · Tejun Heo
Quoted 5 lines · Dan Carpenter
The "
qc->scsicmd" could be null so I moved the dereference inside the check. This was introduced by70b25f890: "[SCSI] fix locking aroundblk_abort_request()"Signed-off-by Dan Carpenter <[email protected]>
Quoted 8 lines
Quoted 3 lines
Ooh.. right.
Asked-by Tejun Heo <[email protected]>Well, oops, yes. Two patches to fix one bug is a bit overboard, I think, plus some code rearrangement to fix the locality of the problem and ensure it doesn't happen again might be useful. What about this.
Looks good.
regards,
dan carpenter