Messages in this thread | | | Date | Thu, 21 Aug 2003 19:27:21 +0200 | From | Andrea Arcangeli <> | Subject | Re: 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/
| |