Re: Possible race condition in i386 global_irq_lock handling.

[Andrea Arcangeli]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/