[lkml]   [1999]   [Feb]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] race-fix for bottom-half-functions [Re: Subtle trouble in remove_bh().]
    On Sun, 31 Jan 1999, Andrea Arcangeli wrote:

    > The point is that to get delayed for 210 usec you must mark the bh with in
    > a window of time that is near zero (the faster the CPU the smaller the
    > window).

    Err, I didn't want to say 210 usec, but 1 jiffy, i.e., 10 msec on i386. Sorry.

    And the window I mean is NOT the one between get/clear_active_bhs(). Look:

    Processor A Processor B
    ----------- -----------
    enters do_irq
    handles irq
    marks some bh
    gets to run_bottom_half()
    acquires both locks
    reads active_bhs enters do_irq
    starts executing them handles irq
    marks some bh
    gets to run_bottom_half()
    does not get the lock, so it exits
    releases both locks and exits exits from do_irq
    exits from do_irq.

    So, the bh marked by B gets delayed until the next interrupt arrives,
    and is not executed ASAP.

    I know that bhs are expected to be delayed in principle (that's why they
    exist), but this delay is not really necessary and is caused by design.

    Some systems, like AmigaOS and it's exec.library avoid this problem by
    strobing the software irq line, which ensures that you always enter the
    soft irq handler ASAP after it has been triggered. That's why I asked why
    m68k does not use this as well...

    >> That's not what I had in mind. I wrote about soft/hardirq_trylock().
    >> Isn't there a (however slight) chance that alway some other processor
    >> than the one in do_bottom_half is holding one of these lock? I am afraid
    >> there is...
    > Hmm, I trust that start_bh_atomic() is SMP safe (if it isn't we should
    > have noticed that because start_bh_atomic() is mainly used to close the
    > window for SMP races ;). But can you show me the window you seen with a
    > simple scheme?

    I was not speaking about races this time. My idea was about theoretical
    chance that some processors execute normal non-irq stuff, some hard-irq
    stuff, but none of them executes soft-irq stuff because the double locking
    always prevents it. Just forget it, it's too artificial.

    BTW, current do_IRQ() does not use get_active_bhs() macro.

    BTW2, the comment at run_bottom_halves() is obsolete.

    Hmm, I suggest that we just stop this discussion, as it does not lead
    anywhere anyway and nobody else seems to think this is an issue...


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

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