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:	Fri, 25 Apr 2008 09:05:18 -0700
From:	Greg KH <greg@...ah.com>
To:	Pekka J Enberg <penberg@...helsinki.fi>
Cc:	Matthew Dharm <mdharm-kernel@...-eyed-alien.net>,
	Alan Stern <stern@...land.harvard.edu>,
	linux-kernel@...r.kernel.org, dsd@...too.org,
	linux-usb@...r.kernel.org, vegardno@....uio.no,
	James.Bottomley@...senPartnership.com, linux-scsi@...r.kernel.org
Subject: Re: [RFC/PATCH] usb-storage: wait for device scanning before
	mounting root

On Fri, Apr 25, 2008 at 11:19:02AM +0300, Pekka J Enberg wrote:
> Hi Matthew,
> 
> On Thu, 24 Apr 2008, Matthew Dharm wrote:
> > > > This also has all sorts of races between do_mounts 'waiting' and the actual
> > > > USB device enumeration.  It's entirely possible that the kernel loads via
> > > > BIOS, the USB drivers are loaded, that forces devices to disconnect/reset,
> > > > and they take a while to re-enumerate.  During that delay, the kernel gets
> > > > to do_mount; now, no devices show in this "waiting for scan" count.
> 
> On Fri, Apr 25, 2008 at 09:30:52AM +0300, Pekka J Enberg wrote:
> > > So how does that happen? ->storage_probe fails and driver core calls it 
> > > later at some point?
> 
> On Fri, 25 Apr 2008, Matthew Dharm wrote:
> > There's no guarantee that storage_probe is going to get called in a timely
> > manner.
> 
> How can we add such a guarantee? Don't we have this problem with any other 
> storage devices?

No we don't.  The problem with USB is that you _never_ know if you are
done discovering all of the devices that are currently plugged into the
bus.  For PCI SCSI and ATA devices, that is not an issue.  So no matter
how many times you think you can mark things "done" you never really
know for sure.

So this means that we can't do this in the kernel, use an initramfs if
you want such functionality, you can sit and spin there and wait until
the device that you think you "know" is there to show up before
continuing on with the boot process.

thanks,

greg k-h
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ