On Tue, Oct 30, 2012 at 11:38 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > > Okay, I see your point. But acquiring the lock here doesn't solve the > problem. Suppose a thread is about to reset a USB mass-storage device. > It acquires the lock and sees that the noio flag is clear. But before > it can issue the reset, another thread sets the noio flag. If the USB mass-storage device is being reseted, the flag should be set already generally. If the flag is still unset, that means the disk/network device isn't added into system(or removed just now), so memory allocation with block I/O should be allowed during the reset. Looks it isn't one problem, isn't it? > I'm not sure what the best solution is. > >> The lock needn't to be held when the function is called inside >> pm_runtime_set_memalloc_noio(), so the bitfield flag should >> be checked directly without holding power lock in dev_memalloc_noio(). > > Yes. > > A couple of other things... Runtime resume can be blocked by runtime > suspend, if a resume is requested while the suspend is in progress. > Therefore the runtime suspend code also needs to save-set-restore the > noio flag. Looks the simplest approach is to handle the noio flag thing at the start and end of rpm_resume. > Also, we should set the noio flag at the start of > usb_stor_control_thread, because everything that thread does can > potentially block an I/O operation. Yes, it should be done, and all GFP_NOIO in usbcore should be converted into GFP_KERNEL together. And the work shouldn't be started until the patchset is merged. > Lastly, pm_runtime_get_memalloc_noio always returns false when > CONFIG_PM_RUNTIME is disabled. But we still need to prevent I/O during > usb_reset_device even when there's no runtime PM. Maybe the simplest > answer is always to set noio during resets. That would also help with > the race described above. I have thought about this. IMO, pm_runtime_get_memalloc_noio should return true always if CONFIG_PM_RUNTIME is unset. Thanks, -- Ming Lei -- 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
