Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp4567670imm; Tue, 11 Sep 2018 14:06:45 -0700 (PDT) X-Google-Smtp-Source: ANB0VdbpiM4TANHAzVM9dC2KTXqVN7IwntCt/zt2PRKyqm6XrAehmM60zZBYOvdY4KObEHiVXitp X-Received: by 2002:a62:1fdd:: with SMTP id l90-v6mr30939384pfj.121.1536700005794; Tue, 11 Sep 2018 14:06:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1536700005; cv=none; d=google.com; s=arc-20160816; b=jSe1LsZkscVU/AQpeANLWjZhLezTRTRQh7TPSkaP3m+Uuvom/1XSlr2ddSutKM96gi +ax3nTIWvrmc2FprBWWcaamsLDRGIUbCpts6TPzYfCD3OZID204VS9Vl7vz8yRmeTCKj qz0mGd/L9cxfQhigxAX40ctEVSj2j0GKUNduC9T2p68i6Ubryh9kxFvjBD6YjrG0E8Cd Z0XRlt83+KjEugVtrDJNNUnpyqaR8ZlZQTV+fFLS/dfQgOfV/iD2kgtmFeLb9hSVHwiI rxYgD0zNQyPv1QmlAqCm+JIK/m2Hs7DdGXGfkXcJDsmEpBDT7BaiLO9hRCSXhMyOdsJv IIkw== 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 :organization:references:in-reply-to:date:cc:to:from:subject :message-id; bh=ldiTi8MhSkPRO9K2KJ7teQ3hQgL2VMTaPtUsgOdxEPk=; b=DEbjBvBu3GdNLwjypeIEDGVHDWmRY3w8j/3WynTK9WujA99qiYELLMUGCo0whvv98L +8yN4EkMyoNb6w08bfDobzpUqFKEIlMhm6wRbp4RGpHnOlqEz+uBSqri0vI31CIpQoN/ 1pbdPf9tUfNW8hhDxd6uCRRpul++HsBqVOC8eWOoryj/FL/J6hib2DAHA97Gl1TaENUn tRhT6pAHfN+Edrs1U9pwUfQ5L/QC7/iNxRm4Ut/5Kn2DVWphwQEYXwu9VlYQfvtylcN4 E2DXGJkmjdg7J4ADf3J6J8j5DLAXCuB3+vZIKF4vNCkOth3LhuiojawHXIS/L8CljCZ2 bMLQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 34-v6si21758868pgo.399.2018.09.11.14.06.30; Tue, 11 Sep 2018 14:06:45 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=codethink.co.uk Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727870AbeILCGn (ORCPT + 99 others); Tue, 11 Sep 2018 22:06:43 -0400 Received: from imap1.codethink.co.uk ([176.9.8.82]:52314 "EHLO imap1.codethink.co.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726870AbeILCGn (ORCPT ); Tue, 11 Sep 2018 22:06:43 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126] helo=xylophone) by imap1.codethink.co.uk with esmtpsa (Exim 4.84_2 #1 (Debian)) id 1fzpqm-0002jn-UN; Tue, 11 Sep 2018 22:05:33 +0100 Message-ID: <1536699932.3024.161.camel@codethink.co.uk> Subject: Re: [PATCH 4.4 51/79] bnxt_en: Fix for system hang if request_irq fails From: Ben Hutchings To: Michael Chan Cc: Vikas Gupta , stable@vger.kernel.org, "David S. Miller" , Sasha Levin , Greg Kroah-Hartman , LKML Date: Tue, 11 Sep 2018 22:05:32 +0100 In-Reply-To: References: <20180823074918.641878835@linuxfoundation.org> <20180823074922.442947994@linuxfoundation.org> <1536696866.3024.151.camel@codethink.co.uk> Organization: Codethink Ltd. Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2018-09-11 at 13:58 -0700, Michael Chan wrote: > On Tue, Sep 11, 2018 at 1:14 PM, Ben Hutchings > wrote: > > On Thu, 2018-08-23 at 09:53 +0200, Greg Kroah-Hartman wrote: > > > 4.4-stable review patch.  If anyone has any objections, please > > > let me know. > > > > > > ------------------ > > > > > > From: Vikas Gupta > > > > > > [ Upstream commit c58387ab1614f6d7fb9e244f214b61e7631421fc ] > > > > > > Fix bug in the error code path when bnxt_request_irq() returns > > > failure. > > > bnxt_disable_napi() should not be called in this error path > > > because > > > NAPI has not been enabled yet. > > > > [...] > > > --- a/drivers/net/ethernet/broadcom/bnxt/bnxt.c > > > +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt.c > > > @@ -4591,7 +4591,7 @@ static int __bnxt_open_nic(struct bnxt * > > >               rc = bnxt_request_irq(bp); > > >               if (rc) { > > >                       netdev_err(bp->dev, "bnxt_request_irq err: > > > %x\n", rc); > > > -                     goto open_err; > > > +                     goto open_err_irq; > > >               } > > >       } > > > > > > @@ -4629,6 +4629,8 @@ static int __bnxt_open_nic(struct bnxt * > > > > > >  open_err: > > >       bnxt_disable_napi(bp); > > > + > > > +open_err_irq: > > >       bnxt_del_napi(bp); > > > > Shouldn't this added statement be conditional on irq_re_init? > > > > Unconditional call is more correct, because when open fails, we clean > up everything, including the NAPI that was added just now or during a > previous call. > > In other words, the NAPI struct is always valid here whether > irq_re_init is true or not.  And we always delete it if open fails. OK, I see. Ben. -- Ben Hutchings, Software Developer   Codethink Ltd https://www.codethink.co.uk/ Dale House, 35 Dale Street Manchester, M1 2HF, United Kingdom