Received: by 10.223.185.116 with SMTP id b49csp5186843wrg; Wed, 7 Mar 2018 07:40:45 -0800 (PST) X-Google-Smtp-Source: AG47ELsexLLwYHnQgZaEyJJN4YiCrAdgmrefZlqmPrDzoTn0r49/efueUnW+U4cjzWbbMqCbl2bx X-Received: by 10.99.122.12 with SMTP id v12mr18646222pgc.128.1520437245373; Wed, 07 Mar 2018 07:40:45 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520437245; cv=none; d=google.com; s=arc-20160816; b=k+nzqClQaksA0LS33CBPDgD4tyILi/cVP+jXpXw9s5a/6b9AEB2Gb1fW69LTPf0drI RTaYbHoo95Dgr3/aAJEtC8jMnHMEDBKghgV6/Ymgts8BaWe/FX3OKLnZBSf8p62EDZks QfdhbAlPt6woBOqUXmOzjJa2QCU5RO/1fo1vPN3132tKQhjjUHFaQqdhxHeCpr3pfUDR KcOkLEzQh3knYyiCTtzBYVAucPno5MHzMFMCtvx/k1NeTPjAVqkBpt2GsCkJlqqnS9Ja MB9lnvwCbKzp5dyAs4Na2FbwvqSmL63sujdHxQvusrbX/1Aga29RlD11y3xMx8H75YFm XvaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:from:subject:cc:to:message-id:date :arc-authentication-results; bh=W2YWrcSLtglJTrZXuQgJQbCZcOulBOq1TUFOr/doYuk=; b=OVEtYAWzdcpvfvMx6l+HR+b0oHhPxMFYNP4eQ2W6yFWGxUeNXdVAOnO2OHhkumS/tJ Ifkm6cUah2MExEjy2UNUUx5o85AdEVlaUpnXO1Ex3WXu/c7jjAOG/J3K7t0VaUIaUDCu qvpHh1ehhOQ4+IeT6Ww6q/pixRr+jf5P9Xmu6CVVsjcbcUboEmFn9qear8KfB0CKfXOk 9TcP7tYm2RkjSQ/uOF02yPJwcx2Z0OatqURYh4gu7Zkd/MsU9ptleDBzDW/3gFB+oRjM s3NT/UO1TlFVWE7kzHl985KJ58AoEHopXxs9DedUqUGdATRa84QzUDjqjZoc+JcZWie+ QJXg== 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 73si14056825pfr.363.2018.03.07.07.40.31; Wed, 07 Mar 2018 07:40:45 -0800 (PST) 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 S933992AbeCGPjH (ORCPT + 99 others); Wed, 7 Mar 2018 10:39:07 -0500 Received: from shards.monkeyblade.net ([184.105.139.130]:53220 "EHLO shards.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933768AbeCGPjD (ORCPT ); Wed, 7 Mar 2018 10:39:03 -0500 Received: from localhost (67.110.78.66.ptr.us.xo.net [67.110.78.66]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: davem-davemloft) by shards.monkeyblade.net (Postfix) with ESMTPSA id 1A16B121807B4; Wed, 7 Mar 2018 07:39:02 -0800 (PST) Date: Wed, 07 Mar 2018 10:39:01 -0500 (EST) Message-Id: <20180307.103901.1771176275743006915.davem@davemloft.net> To: arushisinghal19971997@gmail.com Cc: jdmason@kudzu.us, jakub.kicinski@netronome.com, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, oss-drivers@netronome.com, outreachy-kernel@googlegroups.com Subject: Re: [PATCH v2] net: ethernet: Drop unnecessary continue From: David Miller In-Reply-To: <20180303161456.GA20194@seema-Inspiron-15-3567> References: <20180303161456.GA20194@seema-Inspiron-15-3567> X-Mailer: Mew version 6.7 on Emacs 25.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.12 (shards.monkeyblade.net [149.20.54.216]); Wed, 07 Mar 2018 07:39:02 -0800 (PST) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Arushi Singhal Date: Sat, 3 Mar 2018 21:44:56 +0530 > Continue at the bottom of a loop are removed. > Issue found using drop_continue.cocci Coccinelle script. > > Signed-off-by: Arushi Singhal > --- > Changes in v2: > - Braces is dropped from if with single statement. Sorry there is no way I am applying this. Just blindly removing continue statements that some static checker or compiler warning mentions is completely unacceptable. Actually _LOOK_ at this code: > if(cards[i].vendor_id) { > for(j=0;j<3;j++) > - if(inb(ioaddr+cards[i].addr_offset+j) != cards[i].vendor_id[j]) { > + if(inb(ioaddr+cards[i].addr_offset+j) != cards[i].vendor_id[j]) > release_region(ioaddr, cards[i].total_size); > - continue; > - } > } The extraneous continue statement is the _least_ of the problems here. This code, if the if() statement triggers, will release the ioaddr region and then _CONTINUE_ the for(j) loop, and try to access the registers using the same 'ioaddr' again. That's actually a _REAL_ bug, and you're making it seem like the behavior is intentional by editing it like this. And the bug probably exists because this entire sequence has misaligned closing curly braces. It makes it look like the continue is for the outer loop, which would be fine. But it's not. It's for the inner loop, and this causes the "use ioaddr after releasing it" bug. Please do not submit patches like this one, it makes for a lot of wasted auditing and review for people. The onus is on you to read and understand the code you are editing before submitting your changes. Thank you.