Hi! > That's right. The fix should be simple: Change the GFP_KERNEL in that > dma_pool_alloc() call to GFP_ATOMIC. That was my first thought too. But changing GFP_KERNEL into GFP_ATOMIC leads to a low memory situation after short time as dma_pool_alloc might fail if there is currently no memory available (the same situation in which the schedule_timeout would be called otherwise: g_serial gadget: acm ttyGS0 can't notify serial state, -12 Practicaly this leads to a broken communication. So no real solution. > It wouldn't be surprising if the same sort of bug occurs at other > places in that driver. Indeed, but most other places where this call chain could occur run in a work_queue, so that's not atomic. Regards, Ole -- Thermotemp GmbH, Embedded-IT Embedded Hard-/ Software and Open Source Development, Integration and Consulting http://www.embedded-it.de Geschäftsstelle Siegen - Steinstraße 67 - D-57072 Siegen - tel +49 (0)271 5513597, +49 (0)271-73681 - fax +49 (0)271 736 97 Hauptsitz - Hademarscher Weg 7 - 13503 Berlin Tel +49 (0)30 4315205 - Fax +49 (0)30 43665002 Geschäftsführer: Jörg Friedrichs, Ole Reinhardt Handelsregister Berlin Charlottenburg HRB 45978 UstID DE 156329280 -- 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
