linux-kernel - Re: 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails

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, 17 Sep 2014 10:25:43 -0400
From:	Paul Gortmaker <paul.gortmaker@...driver.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
CC:	Pavel Machek <pavel@...x.de>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Dinh Nguyen <dinh.linux@...il.com>,
	Jaehoon Chung <jh80.chung@...sung.com>,
	Dinh Nguyen <dinguyen@...era.com>,
	Kevin Hilman <khilman@...aro.org>,
	Olof Johansson <olof@...om.net>, Arnd Bergmann <arnd@...db.de>,
	<arm@...nel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails

[Re: 3.17-rc2: root=/dev/mmcblk0p2 command line parsing fails] On 17/09/2014 (Wed 14:20) Russell King - ARM Linux wrote:

[...]

> I think the problem may be 4dfe694f616e00e6fd83e5bbcd7a3c4d7113493d
> ("init: make rootdelay=N consistent with rootwait behaviour") which
> was merged during the recent window.  This moved the delay after the
> saved_root_name[] handling.  As we can see in the SDP4430 case, the
> order was:

[...]

> 
> 
> If ROOT_DEV was still zero, and root_wait was set (it isn't) we'd then
> try to re-evaluate ROOT_DEV.  ROOT_DEV must be set to mount the rootfs,
> and we can see from the above failure messages that it was still zero.
> That works out, because this code would never be run with root_wait=false.
> 
> The reason it used to work is because the delay came _before_ the first
> "if" above, so causing the first ROOT_DEV lookup to succeed.
> 
> I think it may be better to move the root_delay handling either immediately
> after md_run_setup(), or we need to re-lookup ROOT_DEV after the delay.
> Paul, any thoughts?

After discussing it more on irc, it seems like moving the delay/wait
handling after md_run_setup [i.e. to the original location of delay vs.
the original location of wait] is probably best.

But, given as the original commit log indicated -- there may be a risk
of other corner cases subtly being broken by such a change, it is
probably best if we just revert the original now, and then try again in
the alternate location in the next dev cycle.  I'll send a revert
shortly.

Thanks for diagnosing this.
Paul.
--

> 
> -- 
> FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
> according to speedtest.net.
--
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/