Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Fri, 7 Apr 2023 10:31:29 -0500
From:   Bjorn Helgaas <helgaas@kernel.org>
To:     Simon Horman <simon.horman@corigine.com>
Cc:     Denis Plotnikov <den-plotnikov@yandex-team.ru>,
        netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
        anirban.chakraborty@qlogic.com, sony.chacko@qlogic.com,
        GR-Linux-NIC-Dev@marvell.com, manishc@marvell.com,
        shshaikh@marvell.com
Subject: Re: [PATCH net-next v2] qlcnic: check pci_reset_function result
Message-ID: <20230407153129.GA3797408@bhelgaas>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZC/b2lP5+MRwcGqb@corigine.com>
Precedence: bulk

On Fri, Apr 07, 2023 at 11:01:14AM +0200, Simon Horman wrote:
> On Fri, Apr 07, 2023 at 10:18:49AM +0300, Denis Plotnikov wrote:
> > Static code analyzer complains to unchecked return value.
> > The result of pci_reset_function() is unchecked.
> > Despite, the issue is on the FLR supported code path and in that
> > case reset can be done with pcie_flr(), the patch uses less invasive
> > approach by adding the result check of pci_reset_function().

Text could possibly be smoothed out a bit, e.g.:

  Static code analyzer complains that the result of
  pci_reset_function() is unchecked.  Check it and return error if
  it fails because the driver relies on the device being reset.

> > Found by Linux Verification Center (linuxtesting.org) with SVACE.
> > 
> > Fixes: 7e2cf4feba05 ("qlcnic: change driver hardware interface mechanism")
> > Signed-off-by: Denis Plotnikov <den-plotnikov@yandex-team.ru>
> 
> Thanks Denis,
> 
> With reference to,
> 
> Link: https://lore.kernel.org/all/20230405193708.GA3632282@bhelgaas/
> 
> I think this is the best approach in lieu of feedback from those
> with knowledge of the hardware / testing on the hardware.

Agreed, looks good to me, too.  It doesn't look like there's much
activity in this driver (except wider-scale cleanups, etc), so I doubt
anybody could be confident that relying pcie_flr() would be safe.

Seem a *little* weird that this reset is done in .ndo_open() instead
of once at probe-time, but that's a much bigger question and not worth
worrying about.

Reviewed-by: Bjorn Helgaas <bhelgaas@google.com>

> Reviewed-by: Simon Horman <simon.horman@corigine.com>
> 
> > ---
> >  drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c | 8 +++++++-
> >  1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
> > index 87f76bac2e463..eb827b86ecae8 100644
> > --- a/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
> > +++ b/drivers/net/ethernet/qlogic/qlcnic/qlcnic_ctx.c
> > @@ -628,7 +628,13 @@ int qlcnic_fw_create_ctx(struct qlcnic_adapter *dev)
> >  	int i, err, ring;
> >  
> >  	if (dev->flags & QLCNIC_NEED_FLR) {
> > -		pci_reset_function(dev->pdev);
> > +		err = pci_reset_function(dev->pdev);
> > +		if (err) {
> > +			dev_err(&dev->pdev->dev,
> > +				"Adapter reset failed (%d). Please reboot\n",
> > +				err);
> > +			return err;
> > +		}
> >  		dev->flags &= ~QLCNIC_NEED_FLR;
> >  	}
> >  
> > -- 
> > 2.25.1
> >