| Message ID | 20170926065809.7980-1-jthumshirn@suse.de (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
On 09/26/2017 08:58 AM, Johannes Thumshirn wrote: > Coverity-scan recently found a possible NULL pointer dereference in > fc_block_scsi_eh() as starget_to_rport() either returns the rport for > the startget or NULL. > > While it is rather unlikely to have fc_block_scsi_eh() called without > an rport associated it's a good idea to catch potential misuses of the > API gracefully. > > Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> > Reviewed-by: Bart Van Assche <bart.vanassche@wdc.com> > --- > > Changes since v1: > - s/WARN_ON/WARN_ON_ONCE/ (Bart) > > --- > drivers/scsi/scsi_transport_fc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c > index ba9d70f8a6a1..38abff7b5dbc 100644 > --- a/drivers/scsi/scsi_transport_fc.c > +++ b/drivers/scsi/scsi_transport_fc.c > @@ -3328,6 +3328,9 @@ int fc_block_scsi_eh(struct scsi_cmnd *cmnd) > { > struct fc_rport *rport = starget_to_rport(scsi_target(cmnd->device)); > > + if (WARN_ON_ONCE(!rport)) > + return 0; > + > return fc_block_rport(rport); > } > EXPORT_SYMBOL(fc_block_scsi_eh); > Reviewed-by: Hannes Reinecke <hare@suse.com> Cheers, Hannes
On 09/26/2017 08:58 AM, Johannes Thumshirn wrote: > Coverity-scan recently found a possible NULL pointer dereference in > fc_block_scsi_eh() as starget_to_rport() either returns the rport for > the startget or NULL. > > While it is rather unlikely to have fc_block_scsi_eh() called without > an rport associated it's a good idea to catch potential misuses of the > API gracefully. > > Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de> > Reviewed-by: Bart Van Assche <bart.vanassche@wdc.com> > --- > > Changes since v1: > - s/WARN_ON/WARN_ON_ONCE/ (Bart) > > --- > drivers/scsi/scsi_transport_fc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c > index ba9d70f8a6a1..38abff7b5dbc 100644 > --- a/drivers/scsi/scsi_transport_fc.c > +++ b/drivers/scsi/scsi_transport_fc.c > @@ -3328,6 +3328,9 @@ int fc_block_scsi_eh(struct scsi_cmnd *cmnd) > { > struct fc_rport *rport = starget_to_rport(scsi_target(cmnd->device)); > > + if (WARN_ON_ONCE(!rport)) > + return 0; Good idea. However, return 0 or FAST_IO_FAIL? I mean the callchains to this function (and of fc_block_rport()) react differently depending on the return value. Returning 0 means that the rport left the blocked state, i.e. is usable for traffic again. If there is no rport at all, I suppose one cannot use it for traffic. If there is any I/O pending on this scope and we return 0, scsi_eh escalates; and if this happens for a host_reset we end up with offlined scsi_devices. I wonder if returning FAST_IO_FAIL would be more appropriate here in this case, in order to have scsi_eh let the pending I/O bubble up for a timely path failover?
diff --git a/drivers/scsi/scsi_transport_fc.c b/drivers/scsi/scsi_transport_fc.c index ba9d70f8a6a1..38abff7b5dbc 100644 --- a/drivers/scsi/scsi_transport_fc.c +++ b/drivers/scsi/scsi_transport_fc.c @@ -3328,6 +3328,9 @@ int fc_block_scsi_eh(struct scsi_cmnd *cmnd) { struct fc_rport *rport = starget_to_rport(scsi_target(cmnd->device)); + if (WARN_ON_ONCE(!rport)) + return 0; + return fc_block_rport(rport); } EXPORT_SYMBOL(fc_block_scsi_eh);