| Message ID | 1350278059-14904-3-git-send-email-ming.lei@canonical.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
On Mon, 15 Oct 2012, Ming Lei wrote: > This patch applies the introduces tsk_memalloc_forbid_io() and > tsk_memalloc_allow_io() to force memory allocation with no I/O > during runtime_resume callback. > > Cc: Alan Stern <stern@rowland.harvard.edu> > Cc: Oliver Neukum <oneukum@suse.de> > Cc: Rafael J. Wysocki <rjw@sisk.pl> > Signed-off-by: Ming Lei <ming.lei@canonical.com> > --- > drivers/base/power/runtime.c | 13 +++++++++++++ > 1 file changed, 13 insertions(+) > > diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c > index 3148b10..76836c1 100644 > --- a/drivers/base/power/runtime.c > +++ b/drivers/base/power/runtime.c > @@ -652,7 +652,20 @@ static int rpm_resume(struct device *dev, int rpmflags) > if (!callback && dev->driver && dev->driver->pm) > callback = dev->driver->pm->runtime_resume; > > + /* > + * Deadlock might be caused if memory allocation with GFP_KERNEL > + * happens inside runtime_resume callback of one block device's > + * ancestor or the block device itself. The easiest approach is > + * to forbid I/O inside runtime_resume of all devices. > + * > + * In fact, it can be done only if the deivce is a block device > + * or there is one block device descendant. But that may become > + * complicated and not efficient because device tree traversing > + * is involved. > + */ > + tsk_memalloc_forbid_io(current); > retval = rpm_callback(callback, dev); > + tsk_memalloc_allow_io(current); This is not so good. What happens if I/O was already forbidden when this function was called? Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Oct 15, 2012 at 10:14 PM, Alan Stern <stern@rowland.harvard.edu> wrote: > On Mon, 15 Oct 2012, Ming Lei wrote: > >> This patch applies the introduces tsk_memalloc_forbid_io() and >> tsk_memalloc_allow_io() to force memory allocation with no I/O >> during runtime_resume callback. >> >> Cc: Alan Stern <stern@rowland.harvard.edu> >> Cc: Oliver Neukum <oneukum@suse.de> >> Cc: Rafael J. Wysocki <rjw@sisk.pl> >> Signed-off-by: Ming Lei <ming.lei@canonical.com> >> --- >> drivers/base/power/runtime.c | 13 +++++++++++++ >> 1 file changed, 13 insertions(+) >> >> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c >> index 3148b10..76836c1 100644 >> --- a/drivers/base/power/runtime.c >> +++ b/drivers/base/power/runtime.c >> @@ -652,7 +652,20 @@ static int rpm_resume(struct device *dev, int rpmflags) >> if (!callback && dev->driver && dev->driver->pm) >> callback = dev->driver->pm->runtime_resume; >> >> + /* >> + * Deadlock might be caused if memory allocation with GFP_KERNEL >> + * happens inside runtime_resume callback of one block device's >> + * ancestor or the block device itself. The easiest approach is >> + * to forbid I/O inside runtime_resume of all devices. >> + * >> + * In fact, it can be done only if the deivce is a block device >> + * or there is one block device descendant. But that may become >> + * complicated and not efficient because device tree traversing >> + * is involved. >> + */ >> + tsk_memalloc_forbid_io(current); >> retval = rpm_callback(callback, dev); >> + tsk_memalloc_allow_io(current); > > This is not so good. What happens if I/O was already forbidden when > this function was called? You are right, the old flag should be saved before forbidding and restored after allowing. Thanks, -- Ming Lei -- To unsubscribe from this list: send the line "unsubscribe linux-pm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c index 3148b10..76836c1 100644 --- a/drivers/base/power/runtime.c +++ b/drivers/base/power/runtime.c @@ -652,7 +652,20 @@ static int rpm_resume(struct device *dev, int rpmflags) if (!callback && dev->driver && dev->driver->pm) callback = dev->driver->pm->runtime_resume; + /* + * Deadlock might be caused if memory allocation with GFP_KERNEL + * happens inside runtime_resume callback of one block device's + * ancestor or the block device itself. The easiest approach is + * to forbid I/O inside runtime_resume of all devices. + * + * In fact, it can be done only if the deivce is a block device + * or there is one block device descendant. But that may become + * complicated and not efficient because device tree traversing + * is involved. + */ + tsk_memalloc_forbid_io(current); retval = rpm_callback(callback, dev); + tsk_memalloc_allow_io(current); if (retval) { __update_runtime_status(dev, RPM_SUSPENDED); pm_runtime_cancel_pending(dev);
This patch applies the introduces tsk_memalloc_forbid_io() and tsk_memalloc_allow_io() to force memory allocation with no I/O during runtime_resume callback. Cc: Alan Stern <stern@rowland.harvard.edu> Cc: Oliver Neukum <oneukum@suse.de> Cc: Rafael J. Wysocki <rjw@sisk.pl> Signed-off-by: Ming Lei <ming.lei@canonical.com> --- drivers/base/power/runtime.c | 13 +++++++++++++ 1 file changed, 13 insertions(+)