linux-kernel - Re: [PATCH] usb: ulpi: don't register drivers if bus doesn't exist

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: <20150527152116.GA1972@kroah.com>
Date:	Wed, 27 May 2015 08:21:16 -0700
From:	Greg KH <gregkh@...uxfoundation.org>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>,
	Tal Shorer <tal.shorer@...il.com>,
	Sudip Mukherjee <sudipm.mukherjee@...il.com>,
	Sasha Levin <sasha.levin@...cle.com>,
	USB list <linux-usb@...r.kernel.org>,
	"<linux-kernel@...r.kernel.org>" <linux-kernel@...r.kernel.org>,
	David Cohen <david.a.cohen@...ux.intel.com>,
	Felipe Balbi <balbi@...com>,
	Lu Baolu <baolu.lu@...ux.intel.com>
Subject: Re: [PATCH] usb: ulpi: don't register drivers if bus doesn't exist

On Wed, May 27, 2015 at 11:16:34AM -0400, Alan Stern wrote:
> On Wed, 27 May 2015, Heikki Krogerus wrote:
> 
> > This problem is not ulpi specific. We have the same issue with every
> > single bus. With a bus like PCI it's just really unlikely to hit it
> > because PCI bus driver uses postcore_initcall. But if there was
> > a PCI driver that used postcore_initcall itself, maybe a gpio
> > controller driver for example, exactly the same panic would happen
> > that we see happening when a driver tries to register itself with ulpi
> > bus before ulpi bus has been registered.
> > 
> > I can appreciate now that fixing the core problem like I2C did is
> > wrong, but I still feel that the driver core should provide something
> > like the helper for checking if the bus was registered already or not.
> > Otherwise all the bus drivers should really have a variable like Sudip
> > suggested for checking it, but that would be boilerplate, no?
> 
> This sounds like a tricky problem.
> 
> What is a driver supposed to do if it wants to register itself with a 
> bus that hasn't been registered yet?  It can't just sit around 
> and wait for the bus to be registered.  But the only alternative is to 
> let its initialization fail, which means the driver will never be used.
> 
> The only solution I can think of is for the driver core to keep a list
> of pending drivers in struct bus_type, for before the bus has been
> registered.  When the bus finally does get registered, the core should
> then register all the drivers waiting on that list.

Ugh, no, that's a mess.  The bus needs to be registered first, if it
wasn't then something "bad" happened in the design, or the registration
failed.  If registration failed, then the driver should also fail when
it tries to register the bus.

Maybe we need to test for this in the driver core, not allowing drivers
for busses that are not registered, that might solve the main problem
here.  I'll try to look at it tonight.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/