On Wed, 31 Oct 2012, Ming Lei wrote:

On Tue, Oct 30, 2012 at 11:38 PM, Alan Stern [off-list ref] wrote:

quoted

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?

As Oliver said, it can be a problem.

quoted

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.

That's okay as long as the only user of pm_runtime_get_memalloc_noio
(apart from the runtime PM core) is usbcore.

Alan Stern

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>