lkml.org 
[lkml]   [2003]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Possible race condition in i386 global_irq_lock handling.
On Thu, Aug 21, 2003 at 07:01:39PM +0200, Manfred Spraul wrote:
> TeJun wrote:
> >static inline void irq_enter(int cpu, int irq)
> >{
> > ++local_irq_count(cpu);
> >
> > while (test_bit(0,&global_irq_lock)) {
> > cpu_relax();
> > }
> >}
> >
> > Is it a race condition or am I getting it horribly wrong? Thx in
> >advance.
>
> Yes, it's a race. Actually a variant of the race that lead to the
> introduction of set_current_state():
>
> test_bit is a simple read instruction. i386 cpus are free to execute it
> early, i.e. they can execute it before the write part of
> "++local_irq_count(cpu)".
>
> I think smp_rmb() is the right barrier - could you write a patch and send
> it to Marcelo?

smb_rmb is enough in practice for x86 (in asm-i386), but not the right
barrier in general because rmb only serializes reads against reads, so
it would also make little sense while reading the i386 code. here you've
to serialize a write against a read so it would be misleading unless you
know exactly the lowlevel implementations of those barriers.

smp_mb() before the while loop should be the correct barrier for all
archs and the asm generated on x86 will be the same.

alpha, ia64 and x86-64 (and probably others) needs it too.

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

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.060 / U:0.072 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site