Re: [PATCH] apm-emulation: Fix mutex race condition

Rafael J. Wysocki
2011-05-03T18:23:51Z

On Tuesday, May 03, 2011, Paul Parsons wrote:
> A process suspending the system (e.g. apm -s) locks apm_mutex at the
> start of apm_ioctl() and keeps it locked while calling pm_suspend().
> A second process trying to ACK the suspend (e.g. apmd) may then block
> in apm_ioctl() trying to lock the same mutex. The first process tries
> to freeze processes, but the ACK process cannot be frozen because
> mutex_lock() is uninterruptible. Consequently pm_suspend() will
> ultimately fail in try_to_freeze_tasks(). This patch allows the ACK
> process to be frozen if it is blocked in apm_ioctl().
>
> Signed-off-by: Paul Parsons <lost.distance@yahoo.com>
> ---
> --- clean-2.6.39-rc5/drivers/char/apm-emulation.c 2011-03-15 01:20:32.000000000 +0000
> +++ linux-2.6.39-rc5/drivers/char/apm-emulation.c 2011-05-03 00:34:05.467660807 +0100
> @@ -275,7 +275,8 @@ apm_ioctl(struct file *filp, u_int cmd,
> if (!as->suser || !as->writer)
> return -EPERM;
>
> - mutex_lock(&apm_mutex);
> + while (mutex_lock_interruptible(&apm_mutex) < 0)
> + try_to_freeze();

Hmm. I'd rather use mutex_trylock() and call try_to_freeze() if
that fails.

Is there anything wrong with this approach?

> switch (cmd) {
> case APM_IOC_SUSPEND:
> mutex_lock(&state_lock);

Jiri, are you going to maintain apm-emulation.c too?

Thanks,
Rafael