lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230407153129.GA3797408@bhelgaas>
Date:   Fri, 7 Apr 2023 10:31:29 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     Simon Horman <simon.horman@...igine.com>
Cc:     Denis Plotnikov <den-plotnikov@...dex-team.ru>,
        netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        anirban.chakraborty@...gic.com, sony.chacko@...gic.com,
        GR-Linux-NIC-Dev@...vell.com, manishc@...vell.com,
        shshaikh@...vell.com
Subject: Re: [PATCH net-next v2] qlcnic: check pci_reset_function result

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@...dex-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@...gle.com>

> Reviewed-by: Simon Horman <simon.horman@...igine.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
> > 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ