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/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:27 EST