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]

Message-ID: <20070510163348.0a117d92@dhcp-252-105.norway.atmel.com>
Date:	Thu, 10 May 2007 16:33:48 +0200
From:	Haavard Skinnemoen <hskinnemoen@...el.com>
To:	Pierre Ossman <drzeus@...eus.cx>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] MMC: Flush mmc workqueue late in the boot sequence

On Thu, 10 May 2007 15:45:54 +0200
Pierre Ossman <drzeus@...eus.cx> wrote:

> Haavard Skinnemoen wrote:
> > 
> > What exactly makes this unreliable? This is done almost exactly the
> > same way for SCSI. See drivers/scsi/scsi_wait_scan.c.
> > 
> 
> I am not against the function of waiting for an initial scan, what I oppose is
> using side effects to achieve that function. I do not want to take
> responsibility for something that easily breaks because we use a kernel
> subsystem for something it wasn't meant for.

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.

> That said, if there is a precedent for achieving this function a certain way, I
> might be convinced to let it in. I'll have a look at that scsi example.

Thanks.

> > I don't know about USB, but root=/dev/mmcblk0p1 used to work before
> > 2.6.20 and it doesn't work anymore. Doesn't that make this a regression?
> > 
> 
> Yes and no. It depends on if it was an official function, or just an effect of
> how things currently were implemented. As far as I can see, it's the latter. The
> MMC layer goes through several steps that could very well get delayed or happen
> in parallel. So the fact that it happened to work the way you wanted it to was
> sheer luck.

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.

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

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