Messages in this thread |  | | Date | Fri, 22 Sep 2000 20:08:45 +0200 | From | Andrea Arcangeli <> | Subject | Re: GCC proposal for "@" asm constraint |
| |
On Fri, Sep 22, 2000 at 10:35:16AM -0700, Linus Torvalds wrote: > > > On Fri, 22 Sep 2000, Andrea Arcangeli wrote: > > > > This patch fixes the spinlock problems in read_lock/write_lock and also some > > alpha SMP race where clear_bit isn't enforcing a memory barrier > > Why would clear_bit() be a memory barrier?
It isn't infact (with "alpha SMP race" I meant the common code places that are assuming clear_bit is a memory barrier while it correctly isn't on the alpha).
> Anything that expects clear_bit() to be a memory barrier should be fixed.
That's what the patch does.
> Anything that wants a spinlock should use the spinlocks. Not the bit ops. > They are atomic, but they are not memory barriers.
Agreed.
For things like TryLockPage we want to not use the spinlock to be allowed to spin not in the bit 0 but in the PG_locked bit (being lock_page a schedule aware lock that's not problematic for the preemptive UP kernel either) and so there we still need a kind of smp_mb__before/after_clear_bit to avoid suprious lock on the bus on IA32 (and IA32 also needs a compiler barrier() too without the foolgcc stuff). Softnet isn't an issue for preemptive UP kernel either because it always only trylock and it wants to save fields too by using different bits in the ->state field.
If you don't like the name smp_mb__before/after_clear_bit (not that I like it too much too) suggestions are welcome. Maybe we could use a single smp_mb__across_bitops() instead? I didn't do that because it would be less finegrined and not completly correct because bitops includes also test_and_set/clear/change_bit that doesn't need an explicit barrier and they does a mb when the lock is taken and they just clobbers "memory". But we could remove the smp_mb__after/before... case making it a smb_mb__across... if you think it's too much finegrined. I thought it was good to remain finegrined and the current macro names are also quite self-documenting.
Andrea - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |