2.6.39-stable review patch.  If anyone has any objections, please let us know.

------------------

From: Jarod Wilson <[email protected]>

commit 6a8c97ac92461ec57e36b10572e78d4221e8faa8 upstream.

We were calling schedule_timeout with the rx thread's task state still
at TASK_RUNNING, which it shouldn't be. Make sure we call
set_current_state(TASK_INTERRUPTIBLE) *before* schedule_timeout, and
we're all good here. I believe this problem was mistakenly introduced in
commit 5bd6b0464b68d429bc8a3fe6595d19c39dfc4d95, and I'm not sure how I
missed it before, as I swear I tested the patchset that was included in,
but alas, stuff happens...

Acked-by: Andy Walls <[email protected]>
Signed-off-by: Jarod Wilson <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

---
 drivers/staging/lirc/lirc_zilog.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -475,14 +475,14 @@ static int lirc_thread(void *arg)
        dprintk("poll thread started\n");
 
        while (!kthread_should_stop()) {
+               set_current_state(TASK_INTERRUPTIBLE);
+
                /* if device not opened, we can sleep half a second */
                if (atomic_read(&ir->open_count) == 0) {
                        schedule_timeout(HZ/2);
                        continue;
                }
 
-               set_current_state(TASK_INTERRUPTIBLE);
-
                /*
                 * This is ~113*2 + 24 + jitter (2*repeat gap + code length).
                 * We use this interval as the chip resets every time you poll


_______________________________________________
stable mailing list
[email protected]
http://linux.kernel.org/mailman/listinfo/stable

Reply via email to