Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751739AbdFJVMZ (ORCPT ); Sat, 10 Jun 2017 17:12:25 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:57408 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751700AbdFJVMY (ORCPT ); Sat, 10 Jun 2017 17:12:24 -0400 Subject: Re: [PATCH] scsi: remove useless variable assignment From: James Bottomley To: "Gustavo A. R. Silva" Cc: "Martin K. Petersen" , linux-scsi@vger.kernel.org, linux-kernel@vger.kernel.org Date: Sat, 10 Jun 2017 14:12:17 -0700 In-Reply-To: <20170518124107.Horde.TAwM83c0HSIrAfOVg_W7two@gator4166.hostgator.com> References: <20170518003043.GA5664@embeddedgus> <1495082398.2840.14.camel@linux.vnet.ibm.com> <20170518124107.Horde.TAwM83c0HSIrAfOVg_W7two@gator4166.hostgator.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17061021-0024-0000-0000-0000028E6B6E X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007209; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000212; SDB=6.00872923; UDB=6.00434354; IPR=6.00653001; BA=6.00005408; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015776; XFM=3.00000015; UTC=2017-06-10 21:12:21 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17061021-0025-0000-0000-00004456207B Message-Id: <1497129137.3598.6.camel@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-10_11:,, 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-1703280000 definitions=main-1706100365 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2311 Lines: 67 On Thu, 2017-05-18 at 12:41 -0500, Gustavo A. R. Silva wrote: > Hi James, > > Quoting James Bottomley : > > > On Wed, 2017-05-17 at 19:30 -0500, Gustavo A. R. Silva wrote: > > > Remove this assignment once the value stored in variable _k_ is > > > overwritten after a few lines. > > > > > > Addresses-Coverity-ID: 1226927 > > > Signed-off-by: Gustavo A. R. Silva > > > --- > > > drivers/scsi/qlogicfas408.c | 1 - > > > 1 file changed, 1 deletion(-) > > > > > > diff --git a/drivers/scsi/qlogicfas408.c > > > b/drivers/scsi/qlogicfas408.c > > > index c3a9151..269440a 100644 > > > --- a/drivers/scsi/qlogicfas408.c > > > +++ b/drivers/scsi/qlogicfas408.c > > > @@ -329,7 +329,6 @@ static unsigned int ql_pcmd(struct scsi_cmnd > > > *cmd) > > > */ > > > if ((k = ql_wai(priv))) > > > return (k << 16); > > > - k = inb(qbase + 5); /* should be 0x10, > > > bus > > > service */ > > > > That doesn't look right to me. inb() is a statement which has an > > effect on the I/O device regardless of whether the returned value > > is > > used or discarded. In this case I think it's being used to clear > > pending interrupts, so removing it will likely cause a phase error. > > > > You are right, I get it. > > In this case I think a patch to ignore the return value could be > applied: > > index c3a9151..8f5339a 100644 > --- a/drivers/scsi/qlogicfas408.c > +++ b/drivers/scsi/qlogicfas408.c > @@ -329,7 +329,7 @@ static unsigned int ql_pcmd(struct scsi_cmnd > *cmd) > */ > if ((k = ql_wai(priv))) > return (k << 16); > - k = inb(qbase + 5); /* should be 0x10, bus > service */ > + inb(qbase + 5); /* should be 0x10, bus service */ > } > > What do you think? Really, no ... fix coverity. The pattern of = inX(something) is perfectly correct kernel code even if the actual value of is never used again. Unless there's some security bug possibility I'm not seeing, I don't think the pattern needs altering. In theory (void)inX() is the slightly more correct way to do this in that it tells the compiler you need to read from here and you're deliberately discarding the value but I don't see any value to enforcing that. James