linux-kernel - Re: [PATCH 1/5] initdev:kernel: Asynchronously-discovered device synchronization, v5

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:	Tue, 5 May 2009 23:47:25 +0800
From:	Ming Lei <tom.leiming@...il.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Arjan van de Ven <arjan@...radead.org>,
	James Bottomley <James.Bottomley@...senPartnership.com>,
	David VomLehn <dvomlehn@...co.com>,
	<linux-kernel@...r.kernel.org>, <akpm@...ux-foundation.org>,
	<linux-usb@...r.kernel.org>, <greg@...ah.com>,
	<linux-scsi@...r.kernel.org>, <netdev@...r.kernel.org>
Subject: Re: [PATCH 1/5] initdev:kernel: Asynchronously-discovered device
 synchronization, v5

On Mon, 4 May 2009 11:07:52 -0400 (EDT)
Alan Stern <stern@...land.harvard.edu> wrote:

> On Mon, 4 May 2009, Arjan van de Ven wrote:
> 
> > > > for normal device probing we already have infrastructure
> > > > though... wait_for_device_probe, driver_probe_done and
> > > > friends... (the scsi scanning thread is being converted to the
> > > > async infrastructure btw)
> > > > 
> > > > do we need to invent more ?
> > > 
> > > I suppose the usb-storage scanning thread could also be converted
> > > to the async infrastructure, although I haven't heard of anybody
> > > working on it.
> > > 
> > > But the USB hub driver's thread (khubd) cannot be converted.  It
> > > is central to the discovery of USB-based block devices.  How
> > > would you handle that?
> > 
> > take a ref in the driver_probe_done() sense, and release it when you
> > know you're done probing....
> > 
> > at that point all existing infrastructure will just work.
> 
> Isn't there still something missing?  The wait_for_device_probe()  
> routine would wait until all attached devices had been probed.  But
> why should prepare_namespace() have to wait that long?  Wouldn't it be
> better to wait only until the root device has been registered?

Yes, maybe David should merge the following patch into the patch
No.5(initdev:kernel: USB and SCSI block init device notification, v3).

Right?

diff --git a/init/do_mounts.c b/init/do_mounts.c
index dd7ee5f..22fd773 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -358,6 +358,12 @@ void __init mount_root(void)
 #endif
 }
 
+static int root_dev_done()
+{
+	return !!(ROOT_DEV = name_to_dev_t(saved_root_name));
+}
+
+
 /*
  * Prepare the namespace - decide what/where to mount, load ramdisks,
etc. */
@@ -398,12 +404,12 @@ void __init prepare_namespace(void)
 		goto out;
 
 	/* wait for any asynchronous scanning to complete */
-	if ((ROOT_DEV == 0) && root_wait) {
+	if (ROOT_DEV == 0 && root_wait) {
 		printk(KERN_INFO "Waiting for root device %s...\n",
 			saved_root_name);
-		while (driver_probe_done() != 0 ||
-			(ROOT_DEV = name_to_dev_t(saved_root_name)) ==
0)
-			msleep(100);
+		do {
+			initdev_wait(BOOTDEV_BLOCK, root_dev_done);
+		} while (!ROOT_DEV);
 		async_synchronize_full();
 	}
 



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