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]

Message-ID: <20150318195141.GD25365@htj.duckdns.org>
Date:	Wed, 18 Mar 2015 15:51:41 -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,

On Wed, Mar 18, 2015 at 12:36:22PM -0700, Dmitry Torokhov wrote:
> Because they are not inherently problematic. I mean from the kernel POV
> they work fine, the question is if your userspace can deal with them or
> not. For example ChromeOS userspace is fine.

async already provides mechanisms to solve the above problem.  This
doesn't have to be an either-or thing.  I still don't get why we
aren't converting drivers properly over to async so that they still
follow the ordering rules where necessary.  What's wrong with just
blacklisting the ones which can't follow ordering rules for now and
lifting the blacklist as they get fixed?  That'd provide a gradual
transition path with the matching incentive for converting the drivers
while not disturbing userland.

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/