lkml.org 
[lkml]   [1998]   [Oct]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch] jiffies wraparound [Re: 2.1.125 Show stopper list: Draft]

    On Sun, 18 Oct 1998, Alan Cox wrote:

    > > It's a beauty wart, it's been there forever, and we know that machines
    > > actually tend to survive it fine. So far I have _one_ person who has
    >
    > 1.2 survives mostly, 2.0 survives mostly, 2.1.x doesnt survive

    hm, i've just reviewed the timer code from this angle again, and there is
    a suspicious piece of code:

    } else if (expires < timer_jiffies) {
    /* can happen if you add a timer with expires == jiffies,
    * or you set a timer to go off in the past
    */
    insert_timer(timer, tv1.vec, tv1.index);
    =====> } else if (idx < 0xffffffffUL) {
    int i = (expires >> (TVR_BITS + 3 * TVN_BITS)) & TVN_MASK;
    insert_timer(timer, tv5.vec, i);
    } else {
    /* Can only get here on architectures with 64-bit jiffies */
    timer->next = timer->prev = timer;
    }

    shouldnt the (idx < 0xffffffffUL) condition be: (idx <= 0xffffffffUL)?

    eg. if we have 'timer_jiffies == 0x0UL' (just wrapped around), and
    'expires == 0xffffffffUL', then we have 'idx == 0xffffffffUL', but
    (expires < timer_jiffies) is not true on a 32 bit box. Thus we get into
    the last branch, which creates a timer with an infinit timeout ...

    but this shouldnt happen too often i think when we just randomly wrap
    jiffies (without heavy load that delays the processing of timer bhs), so i
    guess there is something else going on.

    -- mingo


    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:45    [W:0.023 / U:0.352 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site