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 17:50:28 -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 02:41:26PM -0700, Dmitry Torokhov wrote:
> You are over-stating the boot order guarantees that storage provides.
> Yes, you can scan devices and partitions simultaneously on the same
> controller, but it will break if controllers are registered in different
> order. And if you are delaying registering cone controller because
> another that you consider "first" has not done probing, you are stalling
> the boot process. It may be OK for "leaf" devices, which disks are
> usually are, bit not when you delaying initialization of a device that
> is in a middle of the device tree.

Can't we make it "transitive"?  Split ->probe() into two parts so that
attaching the leaf devices run from the completion part of the split
->probe().  Sure, a lot of userlands we have nowadays can handle probe
order changing but we stil have use cases where the order matters.
Why introduce two separate behaviors when we can make the pararell
ordering transitive?

Doing things based on a big switch is going to create two largely
separate modes of operations.  For a lot of cases, the gain in boot
time might not be enough to turn on the switch and we sure can't
default to turning it on.  This is a deviation we can avoid with
reasonable amount of effort.  The trade-off seems pretty clear to me.

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/