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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 13 May 2007 15:34:51 +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:
> 
> You're right about my assumptions. Are there any existing drivers that
> break them? Are there even any usb-based controllers around? I though
> most usb-mmc controllers used the USB Mass Storage class and thus
> don't use the mmc subsystem at all.
> 

Yes, but they might show up in the future. My point was that we know of
scenarios that will break this, so it won't be a universal solution (even though
it might work right now).

> 
> I see. The flush_workqueue approach might end up waiting for other
> things than just scanning, is that the problem? Would it be better to
> add a per-host "inital scan complete" completion that we could wait on
> instead?
> 

That would be a cleaner solution yes. That way we don't exploit any current
behaviour that might change in the future.

> 
> I'm not sure how many embedded people actually know how to build an
> initrd for a custom board.
> 

All the ones I have on my desk right now use initrd. ;)

> 
> But if you don't want this issue fixed (i.e. you don't think of it as
> an issue) I guess I have to either start working on yet another initrd
> setup or just apply the patch to our vendor kernel and be done with it.
> The latter certainly is the most tempting, but I suppose the former is
> more like how things are supposed to be done in the future.
> 

Of course I see it as an issue. My concern is if we gain more than we lose.

I had a chat with David Woodhouse and Segher Boessenkool and I think we have
another approach. Basically, we move the waiting which would normally go into
the initrd and move it into the kernel. So you get something like:

"Waiting for root device /dev/mmcblk0p1..."

The only problem here is if the device never shows up, but if that was the case
you would previously get a panic, so it should not be any worse.

Does that sound like something that would work for you? From my point of view
it's a much cleaner solution that has the benefit of not being tied into a
certain subsystem (i.e. this would "fix" usb aswell).

Rgds
Pierre

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