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