Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754367AbdIZJLc convert rfc822-to-8bit (ORCPT ); Tue, 26 Sep 2017 05:11:32 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:36716 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751840AbdIZJLa (ORCPT ); Tue, 26 Sep 2017 05:11:30 -0400 Subject: Re: [PATCH v2 1/1] scsi: fc: check for rport presence in fc_block_scsi_eh To: Johannes Thumshirn , "Martin K . Petersen" Cc: Linux SCSI Mailinglist , Linux Kernel Mailinglist , Hannes Reinecke , Bart Van Assche , Christoph Hellwig References: <20170926065809.7980-1-jthumshirn@suse.de> From: Steffen Maier Date: Tue, 26 Sep 2017 11:09:13 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <20170926065809.7980-1-jthumshirn@suse.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8BIT X-TM-AS-GCONF: 00 x-cbid: 17092609-0020-0000-0000-000003BB1EB5 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17092609-0021-0000-0000-0000424CF5C2 Message-Id: <65ae4ea5-8892-38fa-4477-36c766d8fc13@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-09-26_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1709260137 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2010 Lines: 57 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 > Reviewed-by: Bart Van Assche > --- > > 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? -- Mit freundlichen Grüßen / Kind regards Steffen Maier Linux on z Systems Development IBM Deutschland Research & Development GmbH Vorsitzende des Aufsichtsrats: Martina Koederitz Geschaeftsfuehrung: Dirk Wittkopp Sitz der Gesellschaft: Boeblingen Registergericht: Amtsgericht Stuttgart, HRB 243294