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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20150318182742.GB25365@htj.duckdns.org>
Date:	Wed, 18 Mar 2015 14:27:42 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
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

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.

Thanks.

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