Oliver Neukum <oliver@xxxxxxxxxx> writes: > On Thursday 11 April 2013 10:31:31 Ming Lei wrote: > >> 'mem_flags' isn't needed any more since we can apply allocation >> of GFP_NOIO automatically in resume path now, and you can always >> use GFP_KERNEL safely. Considered that it is a API, please don't >> introduce it. > > The automatic system goes a long way, but there are corner cases, for example > work queues, which still need mem_flags. My immediate thought was that someone also might want to use this new API from atomic context, e.g. calling it directly from an URB callback. But that is of course not possible taking a mutex. Could the lock preventing interrupt_count maybe be a spinlock instead? Or am I on the completely wrong track here? In any case, I don't see the point unnecessarily limiting the API by dropping the memflags. What possible problem would that solve? Bjørn -- 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
