On Tue, Oct 30, 2012 at 11:38 PM, Alan Stern [off-list ref] 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.

quoted

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