linux-kernel - Re: [PATCH 6/8] amd64_edac: enforce synchronous probe

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, 18 Mar 2015 11:37:31 -0700
From:	Dmitry Torokhov <dmitry.torokhov@...il.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	"Luis R . Rodriguez" <mcgrof@...e.com>,
	linux-kernel@...r.kernel.org,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Olof Johansson <olof@...om.net>,
	Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Subject: Re: [PATCH 6/8] amd64_edac: enforce synchronous probe

On Wed, Mar 18, 2015 at 02:27:42PM -0400, Tejun Heo wrote:
> Hello, Dmitry.
> 
> On Wed, Mar 18, 2015 at 11:23:18AM -0700, Dmitry Torokhov wrote:
> > > Is this even useful for most drivers?
> > 
> > Define useful. In my tests I was able to shave 2-3 seconds (out of 8-10)
> > of boot time for the board I was trying it on. Useful for our use case,
> > not so useful for others.
> 
> That definitely counts as useful in my book.
> 
> > >  If not, let's just stick with
> > > whitelisting.  If it is useful, I worry that we're quite unlikely to
> > > build working blacklist with this approach.  idk, having both white
> > > and blacklists tend to end badly.
> > 
> > I will try fixing the amd64_edac driver, but I consider
> > FORCE_SYNCHRONOUS at the moment as an aid for use when trying
> > fully-asynchronous probing. OTOH I wonder how many more drivers do what
> > edac does and try to do post-binding setups... and whether it makes
> > sense to actually try and fix them.
> 
> Just to be clear, I'm not saying we need to fix amd64_edac for async
> probing.  It's fine if this is something generally useful and some
> need to be blacklisted, but in that case let's please drop the
> whitelist or at least have a concrete plan to drop the whitelist -
> e.g. if we're already too late in this dev cycle, we can merge the
> code w/ both white and blacklists now and try to enable it at the
> start of the next merge window, but let's make sure we remove it in a
> timely manner.

I do not believe that we will be able to activate asynchronous probing
by default in the next 2, 3, 4 merge windows: distributions will have to
try and use it and see if they are ready for it. However there are
drivers (slow to probe, usually input) that we do know are OK to be
probed asynchronously even today (because the rest of the infrastructure
dealing with input has been converted to deal with hotplug and devices
coming and going in random order at random points of time). Thus
whitelist is useful for now to reduce boot times even if the rest of the
system is probed synchronously because you are not quite ready for your
root device to jump around.

Thanks.

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