On Thursday 11 October 2012 10:36:22 Alan Stern wrote: > It's worse than you may realize. When a SCSI disk is suspended, all of > its ancestor devices may be suspended too. Pages can't be read in from > the drive until all those ancestors are resumed. This means that all > runtime resume code paths for all drivers that could be bound to an > ancestor of a block device must avoid GFP_KERNEL. In practice it's > probably easiest for the runtime PM core to use tsk_set_allowd_gfp() > before calling any runtime_resume method. > > Or at least, this will be true when sd supports nontrivial autosuspend. Up to now, I've found three driver for which tsk_set_allowd_gfp() wouldn't do the job. They boil down into two types of errors. That is surprisingly good. First we have workqueues. bas-gigaset is a good example. The driver kills a scheduled work in pre_reset(). If this is done synchronously the driver may need to wait for a memory allocation inside the work. In principle we could provide a workqueue limited to GFP_NOIO. Is that worth it, or do we just check? Second there is a problem just like priority inversion with realtime tasks. usb-skeleton and ati_remote2 They take mutexes which are also taken in other code paths. So the error handler may need to wait for a mutex to be dropped which can only happen if a memory allocation succeeds, which is waiting for the error handler. usb-skeleton is even worse, as it does copy_to_user(). I guess copy_to/from_user must simply not be done under such a mutex. I am afraid there is no generic solution in the last two cases. What do you think? 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
