lkml.org 
[lkml]   [2010]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH][RT] futex: protect against pi_blocked_on corruption during requeue PI
    On Tue, 13 Jul 2010, Thomas Gleixner wrote:
    > On Tue, 13 Jul 2010, Darren Hart wrote:
    >
    > > --- a/kernel/rtmutex.c
    > > +++ b/kernel/rtmutex.c
    > > @@ -227,7 +227,7 @@ static int rt_mutex_adjust_prio_chain(struct task_struct *task,
    > > * reached or the state of the chain has changed while we
    > > * dropped the locks.
    > > */
    > > - if (!waiter || !waiter->task)
    > > + if (!waiter || (long)waiter == PI_WAKEUP_INPROGRESS || !waiter->task)
    > > goto out_unlock_pi;
    >
    > Why do we need that check ? Either the requeue succeeded then
    > task->pi_blocked_on is set to the real waiter or the wakeup won and
    > we are in no lock chain.
    >
    > If we ever find a waiter with PI_WAKEUP_INPROGRESS set in
    > rt_mutex_adjust_prio_chain() then it's a bug nothing else.

    Grrr, I'm wrong. If we take hb->lock in the fast path then something
    else might try to boost us and trip over this :(

    This code causes braindamage. I really wonder whether we need to
    remove it according to the "United Nations Convention against Torture
    and Other Cruel, Inhuman or Degrading Treatment or Punishment".

    > > @@ -6377,7 +6379,8 @@ void task_setprio(struct task_struct *p, int prio)
    > > */
    > > if (unlikely(p == rq->idle)) {
    > > WARN_ON(p != rq->curr);
    > > - WARN_ON(p->pi_blocked_on);
    > > + WARN_ON(p->pi_blocked_on &&
    > > + (long)p->pi_blocked_on != PI_WAKEUP_INPROGRESS);
    >
    > Yuck. Paranoia ? If we ever requeue idle, then .....

    At least one which is bogus :)

    Thanks,

    tglx


    \
     
     \ /
      Last update: 2010-07-13 12:31    [W:0.030 / U:30.532 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site