linux-kernel - Re: [PATCH] nubus: Unconditionally register bus type

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]

Date:   Mon, 7 May 2018 16:45:11 +0200
From:   Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:     Finn Thain <fthain@...egraphics.com.au>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] nubus: Unconditionally register bus type

On Mon, May 07, 2018 at 02:53:13PM +0200, Geert Uytterhoeven wrote:
> Hi Finn,
> 
> (responding immediately to patches doing non-kosher things ;-)
> 
> On Mon, May 7, 2018 at 1:57 AM, Finn Thain <fthain@...egraphics.com.au> wrote:
> > On Sun, 6 May 2018, Greg Kroah-Hartman wrote:
> >> > > Why not just have an "bus is registered" flag in your driver
> >> > > register function that refuses to let drivers register with the
> >> > > driver core if it isn't set?
> >> >
> >> > Perhaps that should happen in the core driver_register() function.
> >> > BUG_ON is frowned upon, after all. Would that be acceptable?
> >>
> >> I don't understand what you mean here, perhaps make a patch to show it?
> >>
> >
> > As an alternative to your suggestion (add flag to avoid the BUG_ON):
> >
> > --- a/drivers/base/driver.c
> > +++ b/drivers/base/driver.c
> > @@ -148,7 +148,10 @@ int driver_register(struct device_driver *drv)
> >         int ret;
> >         struct device_driver *other;
> >
> > -       BUG_ON(!drv->bus->p);
> > +       if (!drv->bus->p) {
> > +               WARN_ONCE(1, "Cannot register driver with invalid bus\n");
> > +               return -EPROBE_DEFER;
> > +       }
> >
> >         if ((drv->bus->probe && drv->probe) ||
> >             (drv->bus->remove && drv->remove) ||
> >
> > I'm not actually proposing this change; just responding to your question.
> 
> The bus_type.p field may be unused by some bus drivers, hence this
> would prevent their drivers from being registered.

bus_type.p is an internal-to-the-driver-core structure, no bus driver
should ever be touching it.  This is a catch to see if someone is using
the driver core incorrectly.

thanks,

greg k-h