Re: [RFC PATCH v1 2/3] PM / Runtime: force memory allocation with no I/O during runtime_resume callbcack

[Rafael J. Wysocki]

On Tuesday 16 of October 2012 23:59:42 Ming Lei wrote:
> This patch applies the introduced memalloc_noio_save() and
> memalloc_noio_restore() to force memory allocation with no I/O
> during runtime_resume callback.
> 
> Cc: Alan Stern <stern@xxxxxxxxxxxxxxxxxxx>
> Cc: Oliver Neukum <oneukum@xxxxxxx>
> Cc: Rafael J. Wysocki <rjw@xxxxxxx>
> Signed-off-by: Ming Lei <ming.lei@xxxxxxxxxxxxx>
> ---
>  drivers/base/power/runtime.c |   14 ++++++++++++++
>  1 file changed, 14 insertions(+)
> 
> diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
> index 3148b10..c71a8f0 100644
> --- a/drivers/base/power/runtime.c
> +++ b/drivers/base/power/runtime.c
> @@ -503,6 +503,7 @@ static int rpm_resume(struct device *dev, int rpmflags)
>  	int (*callback)(struct device *);
>  	struct device *parent = NULL;
>  	int retval = 0;
> +	unsigned int noio_flag;
>  
>  	trace_rpm_resume(dev, rpmflags);
>  
> @@ -652,7 +653,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.
> +	 */
> +	memalloc_noio_save(noio_flag);
>  	retval = rpm_callback(callback, dev);
> +	memalloc_noio_restore(noio_flag);
>  	if (retval) {
>  		__update_runtime_status(dev, RPM_SUSPENDED);
>  		pm_runtime_cancel_pending(dev);

This appears to be a bit too heavy handed.  First of all, it seems to affect
all memory allocations going in parallel with the resume callback.  Second,
it affects all resume callbacks, not only those where the problem really
appears.  As a result, we are likely to get some memory allocation failures
that don't happen without the patch and don't really need to happen at all.

Thanks,
Rafael


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/