[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4EFB8523.6080708@gmail.com>
Date: Wed, 28 Dec 2011 16:07:47 -0500
From: KOSAKI Motohiro <kosaki.motohiro@...il.com>
To: Oleg Nesterov <oleg@...hat.com>
CC: Yasunori Goto <y-goto@...fujitsu.com>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...e.hu>,
Hiroyuki KAMEZAWA <kamezawa.hiroyu@...fujitsu.com>,
Motohiro Kosaki <kosaki.motohiro@...fujitsu.com>,
Linux Kernel ML <linux-kernel@...r.kernel.org>
Subject: Re: [BUG] TASK_DEAD task is able to be woken up in special condition
(12/26/11 12:11 PM), Oleg Nesterov wrote:
> On 12/26, Yasunori Goto wrote:
>>
>>>
>>> IIRC, this was already discussed a bit. Say, try_to_wake_up(TASK_INTERRUPTIBLE)
>>> can wakeup a TASK_UNINTERRUPTIBLE task if it temporary sets INTERRUPTIBLE but
>>> doesn't call schedule() in this state.
>>
>> Oleg-san,
>>
>> Could you point the discussion?
>> I don't understand yet how it occurred...
>
> Suppose that the task T does
>
> set_current_state(TASK_INTERRUPTIBLE);
>
> set_current_state(TASK_UNINTERRUPTIBLE);
> schedule();
>
> try_to_wake_up(TASK_UNINTERRUPTIBLE) in between can observe this task
> in TASK_INTERRUPTIBLE state. Then it can set RUNNING/WAKING after T
> sets ->state = TASK_UNINTERRUPTIBLE.
>
> For example, this is possibly if T simply does wait_event() twice when
> the the 1st wait_event() doesn't sleep.
>
> Basically this is the same race you described, but I think you found
> the case when we can't tolerate the spurious wakeup.
Hi
I looked at scheduler code today briefly. now I'm afraid following code
have similar race.
if (task_contributes_to_load(p))
rq->nr_uninterruptible--;
Can't following schenario be happen?
CPU0 CPU1
--------------------------------------------------------
deactivate_task()
task->state = TASK_UNINTERRUPTIBLE;
activate_task()
rq->nr_uninterruptible--;
schedule()
deactivate_task()
rq->nr_uninterruptible++;
Totally, nr_uninterruptible wasn't incremented.
I'm still not sure. I need to read more sched code.
--
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