Re: [RFC][PATCH 0/2] Make sparcv8 work again on cas enabled hardware

[David Miller <davem at davemloft dot net>]

From: Torvald Riegel <triegel@redhat.com>
Date: Tue, 01 Nov 2016 17:46:41 +0100

> On Tue, 2016-11-01 at 12:09 -0400, David Miller wrote:
>> From: Torvald Riegel <triegel@redhat.com>
>> Date: Tue, 01 Nov 2016 16:59:44 +0100
>> 
>> > On Tue, 2016-11-01 at 16:07 +0100, Andreas Larsson wrote:
>> >> Any comments are most welcome. The spin lock based sparcv8 semaphore
>> >> implementation is currently unchanged by this patchset, but I would say
>> >> that that should go as well.
>> > 
>> > Agreed.
>> 
>> I think tossing out all of the ldstub based v8 code is not wise.
>> 
>> I was envisioning adding code to use ldstub on v8 when CAS is not
>> available in order to maintain the status quo of what worked and
>> was functional before the changes which introduced this problem
>> for v8 in the first place.
>> 
>> Having that in place until the kernel-side atomics could be
>> implemented, propagated, and supported in glibc would be a nice
>> intermediate state compared to what we have now.
> 
> How do you intend to make the synchronization primitives work whose
> implementation requires a CAS and for which nobody has provided an
> alternative implementation that does not require CAS?

The pure userland version will do what has been done for decades,
by using a spinlock that protects the word we want to do atomic
operations upon.  A hash table of spinlocks is another option.

When kernel side support exists that version would do the operation
entirely inside of the kernel using whatever internal synchronization
primitive it deems appropriate.  It should be invisible to the user.