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]

Date:	Wed, 27 May 2015 11:16:34 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Heikki Krogerus <heikki.krogerus@...ux.intel.com>
cc:	Greg KH <gregkh@...uxfoundation.org>,
	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, 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.

Alan Stern

--
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/