lkml.org 
[lkml]   [2012]   [Jan]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [BUG] TASK_DEAD task is able to be woken up in special condition
    From
    Date
    On Tue, 2012-01-24 at 13:01 -0500, KOSAKI Motohiro wrote:
    > On 1/24/2012 5:23 AM, Peter Zijlstra wrote:
    > > On Wed, 2011-12-28 at 16:07 -0500, KOSAKI Motohiro wrote:
    > >> 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.
    > >
    > > You shouldn't ever set another tasks ->state.
    >
    > I'm sorry. I haven't catch your point. I think following step is
    > valid kernel code. Do you disagree?
    >
    > >> task->state = TASK_UNINTERRUPTIBLE;
    > >> schedule()

    I think you meant:
    __set_current_state(TASK_UNINTERRUPTIBLE);
    schedule();

    The way you wrote it, task doesn't have to be current, so could be doing
    the bad thing Peter pointed out, diddling *another* tasks ->state.

    -Mike



    \
     
     \ /
      Last update: 2012-01-25 07:17    [W:0.021 / U:0.476 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site