linux-kernel - Re: Wait for console to become available, v3.2

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, 24 Apr 2009 14:32:38 -0700
From:	David VomLehn <dvomlehn@...co.com>
To:	Alan Stern <stern@...land.harvard.edu>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	Jamie Lokier <jamie@...reable.org>,
	Ingo Molnar <mingo@...e.hu>,
	Arjan van de Ven <arjan@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linux USB Mailing List <linux-usb@...r.kernel.org>,
	Linux Embedded Mailing List <linux-embedded@...r.kernel.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: Wait for console to become available, v3.2

On Fri, Apr 24, 2009 at 03:20:42PM -0400, Alan Stern wrote:
> On Thu, 23 Apr 2009, David VomLehn wrote:
> 
> > I'm still scratching my head, trying to figure out where I can tap into the
> > 'USB notion of "all devices that were present at boot time have been probed"'
> > that Alan mentions above, so I don't have a specific implementation yet. I'm
> > open to any tips in this area.
> 
> This is a general notion; it applies to all subsystems that do
> asynchronous device discovery or registration.  The idea is simple
> enough: Keep a count of all devices which are known or suspected to be
> present, and decrement the count each time one of them is registered or
> determined not to exist.  When the count first reaches 0, all devices
> that were present (or reachable) at boot time will have been
> registered.
> 
> Isn't this basically what you had in mind?  If you're concerned about 
> the USB implementation, don't be -- I can write it quite easily.

I will absolutely take you up on your offer to lash this into USB. I'm still
fine-tuning a few details but will send out a patch soon, probably today. It's
a bit hard to test it and I'm sure it will need revision, but it will help a
whole bunch to have a USB implementation to play with.

> It's not just hot-pluggable devices.  These ideas are appropriate 
> whenever detection or registration is asynchronous.

This is very true, and I should modify the nomenclature to reflect this.

> > There currently two types supported:
> > -	consoles
> > -	network devices
> 
> You might as well add block devices too.

Yes, we should. My guess is block devices that hang off of buses besides USB
would be able to use this.

> > bus_bootdev_initialized(int bootdev_mask)
> > 	This function must be called by the bus support code after it calls the
> > 	initialiation function for a boot device. Every call to
> > 	bus_bootdev_found must be matched by a call to
> > 	bus_bootdev_initialized with the same bootdev_mask.
> 
> Even if the device can't be initialized for some reason, or if it turns
> out not the be the sort of boot device originally thought, this
> function still has to be called.  That should be made extremely clear.

True, and I was hoping that was clear enough, but I'll go back and emphasize
this more.

> > 	Device initialization functions must have called the appropriate
> > 	registration function for that device before bus_bootdev_initialized
> > 	is called. So, for console devices, register_console must be called
> > 	before bus_bootdev_initialized, and for network devices,
> > 	register_netdevice must be called first.
> 
> It's not clear how either of these two functions is bus-specific.

They aren't, not directly.  I *think* there isn't a problem here, but it
is certainly possible that the driver wouldn't register the device until some
time after its probe function is called. If that's the case, we would still
have a race condition when we went to use the device, which would defeat the
whole purpose of this change. Determining whether actually have a problem
here is probably too difficult to do beforehand; if an issue exists will find
it during use. Not the ideal approach, but this is engineering and not math.

> This looks like a good plan and not hard to implement.  It even should 
> be possible to fit USB disk drives into the scheme.

That would definitely rock. 

> Alan Stern

David VomLehn
--
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/