[lkml]   [2006]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [ANNOUNCE] 2.6.15-rc5-hrt2 - hrtimers based high resolution patches
    On Tue, 2006-01-10 at 18:59 -0500, Steven Rostedt wrote:
    > And this _is_ protected, but I just discovered that this does _not_
    > protect against hrtimer_start!
    > In hrtimer_start we have:
    > base = lock_hrtimer_base(timer, &flags);
    > /* Remove an active timer from the queue: */
    > remove_hrtimer(timer, base);
    > Which can be called after that spin_unlock_irq is done by the
    > run_hrtimer_queue, and we will hit a bug (as I did). This is not an
    > easy race to hit.

    Right, but there should be actually no use case where this happens.

    For now I prefer to add a

    BUG_ON(base->curr_timer == timer);

    into hrtimer_start to find the real reason.

    > Here's an example of a race for this problem:
    > In posix-timers.c: commen_timer_set:
    > If we get preempted between hrtimer_try_to_cancel and
    > hrtimer_restart.
    > Then a new thread adds the timer back (by a threaded program).

    I don't see how this should happen.

    timr = lock_timer(timer_id, flag);

    Now the k_itimer, which is the container of the hrtimer is locked.

    if (hrtimer_try_to_cancel() < 0)
    return TIMER_RETRY;

    back in sys_timer_settime()


    So how gets this timer added back, when the container lock is held
    across the complete operation ?

    > Now the question is what's the right solution? Can hrtimer_start
    > schedule? Probably not, maybe we should add something to check this and
    > have hrtimer_start return -1 if it is running, and let who ever called
    > it figure out what to do? Maybe have a hrtimer_cancel_start atomic
    > operation? As well as a hrtimer_try_to_cancel_start?

    The posix timer code does already the Right Thing, as it uses
    hrtimer_try_to_cancel() and reacts on the return value. This is
    necessary to prevent a dead lock with the k_itimer lock.

    I try to reproduce this with your test program on my test boxes.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-01-17 18:37    [W:0.021 / U:123.808 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site