[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 Mon, 1 Feb 1999, Patrik Rak wrote:

> 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.

Right, but I don't think it's an issue and I am not going to change it.

> 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.

The point is that you marked the bh while do_bottom_half() was running on
the other CPU and the bh you marked will wait for the next
do_bottom_half() to run. Yes, it could be more finegrined, but as just
said I don't think it's an issue...

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


> BTW2, the comment at run_bottom_halves() is obsolete.

Which? ;)

> 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...

I don't think this is an issue too (and it's sure not a race ;).

Andrea Arcangeli

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.054 / U:8.364 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site