linux-kernel - Re: [RFC PATCH 0/5] driver core: driver probe asynchronously

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:	Sat, 8 Sep 2012 19:57:02 -0700
From:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To:	Ming Lei <ming.lei@...onical.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Takashi Iwai <tiwai@...e.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/5] driver core: driver probe asynchronously

On Sun, Sep 09, 2012 at 07:25:15AM +0800, Ming Lei wrote:
> Hi,
> 
> This patchset implements asynchronous driver probe for driver_register,
> and try to address the below problems about driver init during
> kernel boot:
> 	- help to solve some dependency problem during kernel boot
> 	(such as, request_firmware is called inside probe when driver
> 	is built in kernel[1])
> 
> The idea behind the patch is very simple:
> 
> 	- seperate driver probe from driver_register and run this part
> 	in one standalone kernel thread context
> 
> 	- so driver_register will become two parts: register the driver
> 	on the bus, and trigger to schedule a kernel thread to do the
> 	driver probe if autoprobe is set

You do realize we tried this out about 5+ years ago, it caused major
problems, no real benefit, and so we removed it (or maybe never did the
final commit with it, it might never have hit Linus's tree due to all of
the problems we found.)

> Fortunately, my OMAP4 based Pandaboard boots fine with the patchset, and
> looks it may work well.
> 
> More or less, some problems might be triggered by these patchset, but
> it should be helpful and not a big deal:
> 	- the dependency problem may be found, and it either exposes
> 	the driver's probelm or help to improve the asynchronous probe
> 	approach
> 
> 	- can use driver_register_sync to work around it
> 
> In summary, there are at least two advantages about asynchronous driver
> probe:
> 	- speedup kernel boot when many drivers are built in kernel

I would be really amazed if this is true in any measurable fashion.
Again, we tried this, and it did seem to be a tiny bit faster, but in
the end, wasn't worth it.

> 	- make driver's probe() not need to consider running something
> 	asynchronously(such as, scsi scan, request_firmware_no_wait, ...),
> 	so easier to write drivers

No, that's a bus issue, not a driver issue.  Busses can do this today,
if they want to, no problem at all.  So, some busses have (maybe, maybe
not, I can't remember, but I think ATA did), and that is the level you
need to do this at, not at the driver core level, sorry.

> It should a very simple way to help to solve the problem[1], without
> any changes on current drivers which call request_firmware() in its
> probe(). BTW, the patchset doesn't solve the problem completely, and
> still some work is needed.

As you state, this doesn't really solve the problem, and will cause a
lot more (think about all the busses that aren't expecting to have their
probe functions called at the same time as other probe functions are
being called.)

So while I applaud the effort, I can't accept this due to the past
history of when it was tried before.

sorry,

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/