wait_for_completion_interruptible does not wait !!
in [Kernel]
|
Prev: PM: Avoid losing wakeup events during suspend
Next: [31/31] HWPOISON: Add a madvise() injector for soft page offlining
From: Suresh Rajashekara on 20 Jun 2010 03:00 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. 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. Application ends up thinking that the headset was either removed/inserted. 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. 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? Can there be a blocking call active while we suspend? 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. Thanks in advance, Suresh PS: It might be unrelated, but I am mentioning it here because I learnt this while debugging the issue. If I use an application scheduled as SCHED_FIFO to suspend the kernel (using a driver ioctl which in turn calls enter_state), the operation fails (kernel aborts the process of suspending after 20 seconds saying some applications failed to freeze). Just changing the application scheduling policy to SCHED_OTHER resolves the issue. I was unable to find an explaination for this. However, my current test applications are scheduled as SCHED_OTHER. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Jiri Slaby on 20 Jun 2010 03:30 On 06/20/2010 08:52 AM, Suresh Rajashekara wrote: > The ioctl waits on a completion variable (using > wait_for_completion_interruptible). .... > I tried wait_for_completion instead, but now the kernel refuses to suspend. Do you check return value of wait_for_completion_interruptible and return its value if nonzero? We need the code to comment, otherwise it's hard to say. -- js -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Alan Stern on 20 Jun 2010 12:00 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(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Suresh Rajashekara on 27 Jun 2010 00:10 On Sun, Jun 20, 2010 at 8:52 AM, Alan Stern <stern(a)rowland.harvard.edu> wrote: > > 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? > Haven't tested it but will reply with the answer once I get a chance to test it. >> 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. > Just for the information of others on the list, here is what we did to solve this issue, we designed a freezer-friendly wrapper around wait_for_completion_interruptible() <SNIP> #define wait_for_completion_freezable(ptr_completion) \ ({ \ int __retval; \ do { \ __retval = wait_for_completion_interruptible( \ ptr_completion); \ if (__retval && !freezing(current)) \ break; \ } while (try_to_freeze()); \ __retval; \ }) </SNIP> Thanks Suresh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mark Brown on 28 Jun 2010 08:30
On Sat, Jun 19, 2010 at 11:52:10PM -0700, 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). There is standard support for headset status reporting via the input layer in mainline, I would recommend implementing your headset detection in terms of this. > The problem starts when we suspend the OMAP. The moment we suspend, > the wait_for_completion_interruptible is interrupted and the ioctl > returns. Application ends up thinking that the headset was either > removed/inserted. 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. The input layer does not have this problem. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |