linux-kernel - Re: [PATCH] PCI: remove type return

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: <CAM_RzfbJMbukzcchCA=HF+=orhx95X8RxNEd7JUg9Vck=pDLFw@mail.gmail.com>
Date: Fri, 9 Aug 2024 09:44:23 -0300
From: Guilherme Giácomo Simões <trintaeoitogc@...il.com>
To: Bjorn Helgaas <helgaas@...nel.org>
Cc: Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>, 
	bhelgaas@...gle.com, linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] PCI: remove type return

Guilherme Giácomo Simões <trintaeoitogc@...il.com> write:
>
> Bjorn Helgaas <helgaas@...nel.org> writes:
> >
> > On Tue, Aug 06, 2024 at 05:54:15PM -0300, Guilherme Giácomo Simões wrote:
> > > Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com> wrote:
> > > > On Sat, 3 Aug 2024, Guilherme Giacomo Simoes wrote:
> > > >
> > > > > I can see that the function pci_hp_add_brigde have a int return
> > > > > propagation.
> > > ...
> >
> > > > The lack of return value checking seems to be on the list in
> > > > pci_hp_add_bridge(). So perhaps the right course of action would be to
> > > > handle return values correctly.
> > >
> > > Ok, so if the right course is for the driver to handle return value,
> > > then this is a
> > > task for the driver developers, because only they know what to do when
> > > pci_hp_add_bridge() doesn't work correctly, right?
> >
> > pci_hp_add_bridge() is only for hotplug drivers, so the list of
> > callers is short and completely under our control.  There's plenty of
> > opportunity for improving this.  Beyond just the return value, all the
> > callers of pci_hp_add_bridge() should be doing much of the same work
> > that could potentially be factored out.
> >
> > Bjorn
>
> Okay, then what the action that the drivers must be do when the add
> bridge is failed?

Maybe we can make a change to the drivers that use pci_hp_add_brigde() to
check the return of the function and return an error to its caller like this:

ret = pci_hp_add_bridge(dev);
if (ret)
    goto out;

I have looked at all the drivers that use pci_hp_add_brigde() and they all have
an out flag to call pci_unlock_rescan_remove() to unlock the mutex and
return a code.
We can return in the out flag the code that is the return of
pci_hp_add_brigde() and
then we can set that return code to some #define to identify the error
that is returned.