Received: by 2002:ac0:a5a7:0:0:0:0:0 with SMTP id m36-v6csp251698imm; Fri, 3 Aug 2018 02:53:52 -0700 (PDT) X-Google-Smtp-Source: AAOMgpf0dfLZD6x1BLlOQsNM8HIg/xzJhN8KogVfIxs7Uw/sNqUy06ng7zySAHH268AozdnTc/IJ X-Received: by 2002:aa7:860b:: with SMTP id p11-v6mr3560395pfn.247.1533290032909; Fri, 03 Aug 2018 02:53:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1533290032; cv=none; d=google.com; s=arc-20160816; b=H00wus2mbg9nHBk1OZweCVRLI5GvoevPVeqLOjeTwf5smdr7mzYkh1gm9nvPQIspKf TNvj2sFaiDwiN8c3PHu1iYyIeCFxFVywEqRNV3U2FsSSswDLHzEXbA69LW4Pgwu1c9XR 7X92vDYPJB2sKRbVqJQcqUGZoRMmW5Upqd/qAqS8nrsehPfVZrAZ1excE9vgFQHPmNxO XfXAXzx6BW/8/QUNHJsd+Mp5xuYX6TdBnTk+wLqYdoHsJqdBe4LllDUvl8F1nE3ZrRps goQ24mzTI6+98n+2fMudaAMcF6D6IqHO6pROCPyQIVmBvTtKcrpxXnc5J2aCJYjeFRqn qgeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=XhIc3rel7xwbwA+lUn0LeQNxRj1fBXT68GWtQAKog+I=; b=uZnGvxFU4mqoozIJCHxLORPWLwKKI3W2ggEFKgjZfRGhuQ5mcQqeWbdYvDaq7plXT1 qIo0Y9Dj1gRtfM7ljve5uhxyzpXSFzaWAERLgyD0C0RAF1Y5cil+EF/aL51rjl/Lfwmo cCpBKQ240j8/dhAmIAQAnlSECNd9InBc2JD7N5bQA1CiLai/rLNYoYaoYLTo+PvPAezO nwvPNDwtpcLWEJQl8oAvCv3znOs5AwyHfyKhR/muX1SRnXpeC7q1qAr4gssQu/ZDiGWB x0eGSBf4NhY6if/3x6rNvPfTUlXR6yRKjjUJhJlhogpRaF6XgXhROwTeBb1Ge8TqZ7Bs WzxQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id c15-v6si3251716plo.232.2018.08.03.02.53.37; Fri, 03 Aug 2018 02:53:52 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1732479AbeHCLsW (ORCPT + 99 others); Fri, 3 Aug 2018 07:48:22 -0400 Received: from mail3-relais-sop.national.inria.fr ([192.134.164.104]:53230 "EHLO mail3-relais-sop.national.inria.fr" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728122AbeHCLsW (ORCPT ); Fri, 3 Aug 2018 07:48:22 -0400 X-IronPort-AV: E=Sophos;i="5.51,438,1526335200"; d="scan'208";a="274881484" Received: from vaio-julia.rsr.lip6.fr ([132.227.76.33]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2018 11:52:48 +0200 Date: Fri, 3 Aug 2018 11:52:45 +0200 (CEST) From: Julia Lawall X-X-Sender: jll@hadrien To: Andy Shevchenko cc: Finn Thain , zhong jiang , Michael Schmitz , "James E . J . Bottomley" , "Martin K. Petersen" , John Garry , linux-scsi , Linux Kernel Mailing List Subject: Re: [PATCH] scsi:NCR5380: remove same check condition in NCR5380_select In-Reply-To: Message-ID: References: <1533179408-20631-1-git-send-email-zhongjiang@huawei.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 3 Aug 2018, Andy Shevchenko wrote: > On Fri, Aug 3, 2018 at 5:24 AM, Finn Thain wrote: > > On Thu, 2 Aug 2018, zhong jiang wrote: > > > >> The same check condition is redundant, so remove one of them. > >> > > > > If you are trying to find redundant code, your coccinelle script is > > dangerously flawed. > > These days too many coccinelle helpers make people think they are > doing right "clean ups" when in the practice they bring the > regressions. > > Julia, is possible by coccinelle to distinguish memory accesses versus > I/O? At least it would increase robustness in some cases. With make coccicheck, the semantic patch should already emit the warning: //# A common source of false positives is when the argument performs a side //# effect. I can modify the rule so that it doesn't report on code that involves function calls. It could lose some desirable warnings, where the function call is just a wrapper for eg extracting some field, but it is probably safer in practice. julia