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-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
