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 09:57:22 +1000 (AEST)
From:   Finn Thain <fthain@...egraphics.com.au>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
cc:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        linux-m68k@...ts.linux-m68k.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] nubus: Unconditionally register bus type

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.

For the bug at hand, I still prefer the patch at the beginning of this 
thread, because it seems to follow the conventional pattern.

> > I found a few drivers that set a flag the way you describe, which 
> > could then be simplified.
> > 
> > But that pattern is rare. Most buses use the postcore_initcall() 
> > pattern, and so my patch took the conventional approach.
> 
> It all depends on link order, not necessarily the postcore stuff.
> 
> > > And then fix your linking error, the bus should come first in link 
> > > order, before your drivers :)
> > > 
> > 
> > I didn't encounter any errors. How shall I reproduce this?
> 
> If you have not seen this error, then why change the code at all if it 
> is working properly?

I never saw the link error you mentioned.

Please see this thread for one example of how to hit the BUG_ON.
https://marc.info/?l=linux-m68k&m=152522162801182&w=2

Another way to trigger the BUG_ON is to set,
CONFIG_ATARI=y
CONFIG_MAC=y
CONFIG_NUBUS=y
CONFIG_MAC8390=y
and try to boot the result on aranym.

-- 

> Most busses do not need this as they have their link order set up 
> correctly, no need to mess with stuff that is not broken :)
> 
> thanks,
> 
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>