linux-kernel - Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering w/ device tree

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-next>] [day] [month] [year] [list]

Message-ID: <5723FCE3.9070308@hurleysoftware.com>
Date:	Fri, 29 Apr 2016 17:31:31 -0700
From:	Peter Hurley <peter@...leysoftware.com>
To:	Doug Anderson <dianders@...omium.org>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Jaehoon Chung <jh80.chung@...sung.com>,
	Shawn Lin <shawn.lin@...k-chips.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Stefan Agner <stefan@...er.ch>,
	"linux-mmc@...r.kernel.org" <linux-mmc@...r.kernel.org>,
	Brian Norris <computersforpeace@...il.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Heiko Stuebner <heiko@...ech.de>,
	Jisheng Zhang <jszhang@...vell.com>,
	"open list:ARM/Rockchip SoC..." <linux-rockchip@...ts.infradead.org>,
	devicetree-spec@...r.kernel.org,
	Mark Rutland <mark.rutland@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Venu Byravarasu <vbyravarasu@...dia.com>,
	Lars-Peter Clausen <lars@...afoo.de>,
	Jon Hunter <jonathanh@...dia.com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	Pawel Moll <pawel.moll@....com>,
	Ian Campbell <ijc+devicetree@...lion.org.uk>,
	Grant Grundler <grundler@...omium.org>,
	Kumar Gala <galak@...eaurora.org>,
	"Luca Porzio (lporzio)" <lporzio@...ron.com>,
	Rob Herring <robh+dt@...nel.org>,
	Chaotian Jing <chaotian.jing@...iatek.com>,
	Sergei Shtylyov <sergei.shtylyov@...entembedded.com>,
	Sudeep Holla <sudeep.holla@....com>,
	zhonghui.fu@...ux.intel.com, kirill.shutemov@...ux.intel.com
Subject: Re: [PATCH v2 0/4] Patches to allow consistent mmc / mmcblk numbering
 w/ device tree

On 04/29/2016 05:03 PM, Doug Anderson wrote:
> Hi,
> 
> On Fri, Apr 29, 2016 at 4:58 PM, Peter Hurley <peter@...leysoftware.com> wrote:
> 
>     On 04/29/2016 04:01 PM, Doug Anderson wrote:
>     > * serial allows numbering devices by alias.
> 
>     Which is in fact a total nightmare.
> 
>     While stable device order is mandatory in serial because of
>     console command line parameters and existing userspace expectations,
>     it is the number one barrier to providing a shared ttyS namespace
>     for mixed uart platforms.
> 
>     Stable device order has a very real (and often unforeseen) maintenance
>     burden.
> 
> 
> Interesting. I wonder if these burdens are unique to serial or shared
> by all the other subsystems that allow ordering? Maybe this is all
> because of legacy reasons?

Well, the specific issue is certainly unique to serial.
But what I was suggesting is that 5 years from now, these patches
could be the "legacy reasons" in mmc.

FWIW, there is already a defacto expectation by boot configurations in the
field that a given mmc block device is stable across boots. The reality
is that 100000's of kernel command lines look like:

	root=/dev/mmcblk0p2

This was a recent regression fixed by Ulf in commit 9aaf3437aa72
("mmc: block: Use the mmc host device index as the mmcblk device index")

> Note that for MMC devices we wouldn't be asserting that _every_
> device has a stable order. Only those known at boot.
> 
> 
>     For example, I noticed these patches are strictly for DT.
>     I'm assuming that's because guaranteeing stable device order for
>     mmc in general is more difficult; eg., by performing minimal scan
>     serially and more expensive portion of the probe async.
> 
> 
> Presumably if there were another system similar to DT where we knew
> all the possible built-in devices right at boot then we could
> extend.
> 
> ...but yes, obviously this wouldn't be a sane thing to do for
> anything probable like PCI or USB.

SCSI does. Here's what Linus said:

"So the *simple* model is to just scan the devices minimally serially,
and allocate the names at that point (so the names are reliable
between boots for the same hardware configuration). And then do the
more expensive device setup asynchronously (ie querying device
information, spinning up disks, whatever - things that can take
anything from milliseonds to several seconds, because they are doing
actual IO). So you'd do some very basic (and _often_ fairly quick)
operations serially, but then try to do the expensive parts
concurrently.

The SCSI layer actually goes a bit further than that: it has a fairly
asynchronous scanning thing, but it does allocate the actual host
device nodes serially, and then it even has an ordered list of
"scanning_hosts" that is used to complete the scanning in-order, so
that the sysfs devices show up in the right order even if things
actually got scanned out-of-order. So scans that finished early will
wait for other scans that are for "earlier" devices, and you end up
with what *looks* ordered to the outside, even if internally it was
all done out-of-order.
"

Regards,
Peter Hurley