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: <20150318221530.GK11485@dtor-ws>
Date:	Wed, 18 Mar 2015 15:15:30 -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 05:50:28PM -0400, Tejun Heo wrote:
> 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?

So let's say that we we have 2 devices D1 and D2 which have
children C1 and C2 with leaves L1 and L2:

Device	Probe time
D1	5
D2	1
C1	2
C2	4
L1	1
L2	1

If we run fully async we will need 8 units to probe everything
(max(D1+C1+L1, D2+C2+L2)). With pausing at each level we'd need 10
units (max(D1, D2) + max(C1, C2) + max(L1, L2).

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

As I mentioned, the benefit / trade-off depends on your point of view.
For servers nobody would care. For consumer devices it is very
important.

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/