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:	Thu, 04 Apr 2013 14:35:04 +0300
From:	Adrian Hunter <adrian.hunter@...el.com>
To:	Sergey Yanovich <ynvich@...il.com>
CC:	Chris Ball <cjb@...top.org>, Ulf Hansson <ulf.hansson@...aro.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linus Walleij <linus.walleij@...aro.org>,
	Jaehoon Chung <jh80.chung@...sung.com>,
	Namjae Jeon <linkinjeon@...il.com>,
	linux-kernel@...r.kernel.org, linux-mmc@...r.kernel.org
Subject: Re: [PATCH v2] wait while adding MMC host to ensure root mounts

On 04/04/13 13:59, Sergey Yanovich wrote:
> On Thu, 2013-04-04 at 09:35 +0300, Adrian Hunter wrote:
>> No,  I am booting from eMMC.
> 
> Well, in this case you should be aware, that your system is not
> concurrency-safe without the patch. It may or may not boot each time
> depending on the large number of factors.

Not true.  You know nothing of my boot time characteristics.

> 
>>> Maybe introduce mmc_is_hosting_root() and do something like:
>>>
>>> -	mmc_flush_scheduled_work();
>>> +	if (mmc_is_hosting_root())
>>> +		mmc_flush_scheduled_work();
>>
>> No, I am booting from eMMC.  Perhaps a host capability:
>>
>> 	if (host->caps2 & MMC_CAP2_ROOTWAIT)
>> 		mmc_flush_scheduled_work();
>>
> 
> Neither my variant, nor yours will help to handle the increased boot
> time.

Not true.  I would not set MMC_CAP2_ROOTWAIT.

> The root cause is that probing several devices is done sequentially and
> mmc was reporting end of its probing before it was actually happening.

Not true.  The probe of the MMC Host Controller finishes when the host
controller is initialized.

> My patch makes mmc report end of probing on-time. The correct way to fix
> the additional delay, my patch introduces, is to rewrite the probing to
> be parallel instead of sequential. I understand that it is much easier
> just to revert the patch.
> 
> If the patch is reverted, something like this somewhere in
> 'init/do_mounts.c' could conditionally activate 'root_wait':
> 
> 	if (mmc_is_hosting_root())
> 		root_wait = 1;
> 
> IMHO this is wrong and my patch is right, but better this than broken
> mmc boot.

No.  Your patch is not right for my platform.

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

Powered by blists - more mailing lists