Am Dienstag, 5. Mai 2009 19:22:53 schrieb Andrew Morton: > On Tue, 5 May 2009 12:44:01 +0200 Oliver Neukum <oliver@xxxxxxxxxx> wrote: > > USB drivers are interface level yet some functions, reset and power > > management, are on a device level. As it is unpredictable whether > > a driver will share a device with a storage driver, all USB drivers as > > far as these functions are concerned must be considered block device > > drivers. That's the reason GFP_NOIO is so prevalent in USB. > > There must be some particular action which flips the thread of control > from one state to the other. eg, taking of a lock. Basically assigning an interface to the storage or ub driver. > > > I wonder how hard it would be to add runtime debugging checks? If > > > > I'd prefer compile time checks. Ideally we'd annotate a function with an > > attribute making the compiler barf if copy_to/from_user or an > > inappropriate kmalloc is used. It can't be perfect due to function > > pointers, but it would be a good start. > > I don't think that would have enough coverage - bugs in this area tend > to come from calling some function which looks innocent, but which > calls some function which calls some function which calls some function > which uses GFP_KERNEL. > > And then there's stuff like "usb takes a mutex which is also taken by > some other thread which does a GFP_KERNEL allocation while holding that > mutex". Yes, but to catch that you'd have to teach lockdep about those functions whose locks are dangerous to share with respect to memory allocation. Is there another way to do that besides labelling dangerous methods? Regards Oliver -- 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
