lkml.org 
[lkml]   [1999]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] race-fix for bottom-half-functions [Re: Subtle trouble in remove_bh().]
On Sat, 30 Jan 1999, Patrik Rak wrote:

> > The fix should be simply to use set/clear_bit instead of &= |= in
> > init_bh/remove_bh. Do you agree?
>
> Yes. (Actually, that's what I already said two messages ago).

Ah, excuse me, I misunderstood, I thought you mean you wanted to protect
the region with the spinlock.

>
> > the double locking is not very nice implementation, is it? You can
> > > delay the software interrupt for whole 210 usec, and in theory,
> >
> > This is true but it's not an issue.
>
> Oh, so 210 usec delay is not a problem? Well, I thought it is whole
> eternity for CPUs today :)

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

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

Andrea Arcangeli


-
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:50    [W:0.581 / U:0.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site