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: <1347176866.2385.100.camel@pasglop>
Date:	Sun, 09 Sep 2012 17:47:46 +1000
From:	Benjamin Herrenschmidt <benh@...nel.crashing.org>
To:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:	Ming Lei <ming.lei@...onical.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Takashi Iwai <tiwai@...e.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/5] driver core: driver probe asynchronously

On Sat, 2012-09-08 at 19:57 -0700, Greg Kroah-Hartman wrote:
> 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. 

Maybe a compromise would be to have ->probe() be called synchronously as
done currently, but to add support for a specific -EAGAIN return from
it, requiring a later asynchronous re-probe ? (Possibly requiring an
explicit trigger)

That would allow drivers who fail some kind of "oddball" dependency (the
firmware load is such as case, there are a few others) to basically
install some kind of notifier and try again later when the dependency
has been fulfilled.

That way existing drivers still behave synchronously, there is no
breakage unless drivers are explicitly modified for async probing.

Cheers,
Ben.


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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ