linux-kernel - RE: [EXT] Re: [PATCH net-next v2 1/4] octeon

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] [day] [month] [year] [list]

Message-ID: <PH0PR18MB47349A78068BB819B1030BB2C78FA@PH0PR18MB4734.namprd18.prod.outlook.com>
Date:   Mon, 11 Dec 2023 06:32:09 +0000
From:   Shinas Rasheed <srasheed@...vell.com>
To:     Simon Horman <horms@...nel.org>
CC:     "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Haseeb Gani <hgani@...vell.com>,
        Vimlesh Kumar <vimleshk@...vell.com>,
        "egallen@...hat.com" <egallen@...hat.com>,
        "mschmidt@...hat.com" <mschmidt@...hat.com>,
        "pabeni@...hat.com" <pabeni@...hat.com>,
        "kuba@...nel.org" <kuba@...nel.org>,
        "davem@...emloft.net" <davem@...emloft.net>,
        "wizhao@...hat.com" <wizhao@...hat.com>,
        "kheib@...hat.com" <kheib@...hat.com>,
        "konguyen@...hat.com" <konguyen@...hat.com>,
        Veerasenareddy Burru <vburru@...vell.com>,
        Sathesh B Edara <sedara@...vell.com>,
        Eric Dumazet <edumazet@...gle.com>
Subject: RE: [EXT] Re: [PATCH net-next v2 1/4] octeon_ep: add PF-VF mailbox
 communication

Hi Simon,

> > +	err = octep_setup_pfvf_mbox(octep_dev);
> > +	if (err) {
> > +		dev_err(&pdev->dev, " pfvf mailbox setup failed\n");
> > +		octep_ctrl_net_uninit(octep_dev);
> > +		return err;
> 
> Hi Shinas,
> 
> This seems inconsistent with other error handling in this function, I
> suspect it is leaking resources. And even if it does not, it's likely to
> lead to such problems as this function is updated in future.  Please
> consider consistently handling error unwinding using goto labels in this
> function.
> 
> I think that means either making sure that octep_delete_pfvf_mbox() can
> handle the case whereby octep_setup_pfvf_mbox() fails. Or including) the
> steps taken by octep_device_cleanup() in the unwind ladder provided by
> goto
> labels (which could be a separate patch, and I suspect to be the best
> approach). But I could well be wrong.

You are correct. I'll update this in the next version. Thanks for reviewing!

Shinas