linux-kernel - Re: [RFC PATCH 1/5] usb-hcd: implement polling a specific usb device

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] [day] [month] [year] [list]

Date:	Mon, 8 Nov 2010 16:59:27 -0500 (EST)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Jason Wessel <jason.wessel@...driver.com>
cc:	gregkh@...e.de, USB list <linux-usb@...r.kernel.org>,
	Kernel development list <linux-kernel@...r.kernel.org>,
	<kgdb-bugreport@...ts.sourceforge.net>,
	Alan Cox <alan@...ux.intel.com>,
	Oliver Neukum <oliver@...kum.org>
Subject: Re: [RFC PATCH 1/5] usb-hcd: implement polling a specific usb device

On Mon, 8 Nov 2010, Jason Wessel wrote:

> > Let's put it this way: Your polling mechanism has conflated two 
> > separate issues.  The matter of polling the host controller driver is 
> > distinct from the question of which URBs to stick on the queue.
> > 
> > While kdb is running, it makes sense to give back only the URBs that 
> > are for the console device.  But if you are polling during the normal 
> > operation of printk and the usb serial console, then there's no reason 
> > not to give back all the URBs that complete during polling.
> > 
> 
> That is an interesting way to look at things...  You metioned I
> conflated to issues, but in my mind they were the same (kdb vs printk
> requiremetns).  I just figured we should do the minimum possible when
> trying to exec a printk() because we want it to be as reliable as
> possible.  I had the following example in mind where a usb camera
> driver executes a pile of printk()'s and the poll kicks in, we would
> only like the completion handler to run for the usb serial device and
> to defer the rest.

It's true that drivers might not expect URB completions to occur in the
middle of a printk.  Particularly on UP systems with interrupts
disabled!  And there is always a possibility of deadlock: If an URB
completion handler takes a spinlock and then calls printk, draining the
queue could end up waiting on the same spinlock.  But of course the
same thing would happen regardless of whether or not URBs are deferred
via the queue.

It seems clear that you don't want to drain the queue while kdb is 
running, so the usb serial console code shouldn't do it.  This in turn 
implies that when polling during normal console operation, URBs should 
not be put on the queue.  Try doing things that way and see if you run 
into trouble.

> What about the printk() case though?  My argument for queuing and
> scheduling was to minimize the ability that printk() will get deferred
> by something else.

I don't think giving back URBs at the end of a printk is any better 
than giving them back in the middle of a printk.  For example, consider 
the case where there are two printk statements in a row.

The place you will really run into trouble is if the driver for the 
USB console serial device includes a printk in its completion handler!

Alan Stern

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