Message-ID: <Pine.LNX.4.44L0.1006201120210.22272-100000@netrider.rowland.org>
Date:	Sun, 20 Jun 2010 11:52:42 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Suresh Rajashekara <suresh.raj+linuxomap@...il.com>
cc:	linux-omap@...r.kernel.org, <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [linux-pm] wait_for_completion_interruptible does not wait !!

On Sat, 19 Jun 2010, Suresh Rajashekara wrote:

> I have an application which calls the ioctl of the codec driver to
> know the status of the headset.
> 
> The ioctl waits on a completion variable (using
> wait_for_completion_interruptible).
> 
> The variable is completed in the interrupt handler, which happens on
> headset insertion/removal. Once the variable is completed, the ioctl
> returns (with appropriate value in the argument) and the application
> decides what to do with the event.

What happens if the variable is completed while nobody is waiting for
it?  The next time somebody tries to wait, won't the wait terminate
immediately?

> Once done handling the event, the application then calls the ioctl
> once again (bascially it polls the audio driver) to know the status of
> the headset. The call is blocked until the headset status changes.
> 
> I am running the system on linux-2.6.29 on a OMAP1 based board. All
> this works well when the OMAP is awake.
> 
> The problem starts when we suspend the OMAP. The moment we suspend,
> the wait_for_completion_interruptible is interrupted and the ioctl
> returns.

Of course.  That's how processes that are blocked in the kernel are
given a chance to enter the freezer.

> Application ends up thinking that the headset was either
> removed/inserted.

It should not think that.  There are other reasons why an ioctl might
return early, such as a genuine signal or two status changes occurring
before the ioctl starts (the next two ioctls will both return
immediately, but the first one will contain the final status and the
second won't contain any status change).

For this to work correctly, the kernel should accumulate a bitmap of
status changes as they occur.  When an ioctl returns, it should provide
the bitmap of all the status changes that have occurred since the last
ioctl (and it should clear the status-change bitmap) along with the
current status.  Otherwise the application has no way to know about
changes that occur between ioctl calls.

> Our system does an aggressive sleep (wakes up every
> 500 ms and sleeps again) and hence the application gets the event of
> headset every 500 ms.

What's wrong with that?  It should be smart enough to realize that most
of these events aren't actual status changes.

> I tried wait_for_completion instead, but now the kernel refuses to suspend.
> 
> I have tried wait queues and mutexs with no success.
> 
> Could anyone please point me how I can resolve this issue? Is there
> any construct which can block inside the kernel during suspend/resume?

Yes: The freezer.

> Can there be a blocking call active while we suspend?

Yes, in theory.  In practice it's not a good idea, since the call 
wouldn't be able to distinguish between an actual signal and the onset 
of a suspend.  You might end up with a call that ignores all signals 
and hence cannot be interrupted.

> Ideally I would resort to a method in which I would signal the process
> when there is a headset event, but I am not free to change the
> application. Its a legacy application and I have to make the kernel
> work for it.

It's not clear that anything needs to be fixed, except possibly the
application.  Hint: See the SA_RESTART flag for sigaction(2).

It also sounds like the application's design may be fundamentally
broken.  Certain kinds of defects cannot be worked around in the
kernel.

Alan Stern

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists