linux-kernel - Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence

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, 10 May 2007 17:58:27 +0200
From:	Pierre Ossman <drzeus@...eus.cx>
To:	Haavard Skinnemoen <hskinnemoen@...el.com>
CC:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence

Haavard Skinnemoen wrote:
> 
> Ok, is there any better way to achieve the same this? As far as I
> can tell, mmc_remove_host() uses mmc_flush_scheduled_work() for the
> same purpose -- it ensures that scans that have already been started
> will have completed before the function continues.
> 

Not quite. mmc_remove_host() doesn't care if a detect has been executed or not,
it only cares about whether or not one is executing right now. So in order for
your patch to work, there must be no way that mmc_finish_detect() is called
before the detect is scheduled.

> 
> I wouldn't call it luck. The way mmc_rescan() is implemented, any scans
> that are started before late_initcall time are completed before
> mmc_finish_detect() returns. The steps are all done synchronously in
> the workqueue function.
> 

Indeed. But it is not by design that they are scheduled before late_initcall().
Also, flushing the workqueue is also not a by-design way of completing a scan,
it just happens to be that way right now.

> And I never realized that using a block device as a parameter to the
> root= parameter could possibly be "unofficial" functionality...?

Then you've learned something new. ;)

Only some devices work that way (generally only those with "simple" interfaces).
And most things are these days behind more advanced buses, more akin to a network.

Generally, not waiting for a lot of hardware is a good thing as it speeds up
boot times. In my mind, the proper way is having a script in an initrd that
waits for just the parts of the hardware that this particular system needs.
Everything else can be brought up in the background.

Rgds
Pierre

Download attachment "signature.asc" of type "application/pgp-signature" (252 bytes)