Re: sparc nptl mystery resolved

[David Miller <davem at davemloft dot net>]

From: Roland McGrath <roland@hack.frob.com>
Date: Fri, 27 Jun 2014 15:15:51 -0700 (PDT)

> Incidentally, the "sparc-specific" code is so similar to the stock code
> that I'd suggest you do some refactoring so it can share most of the source
> instead of duplicating it.  But I haven't looked at all the details, so
> maybe it's less similar than I think.

The difference is that for sparc 32-bit we put an explicit byte
spinlock into the semaphore structures since pre-v9 32-bit we lack
atomic operations other than "ldstub" (load and store byte atomic).

That's also why we have the funny 24-bit atomic integers, so we can
use the upper 8-bits for the byte spinlock.

This strategy, of cource, has a whole host of issues.  Worst of which
is that we can (and do) deadlock with signals.

I wish Jakub Jelink and I had to foresight decades ago to do what
other platforms do to handle this situation, which is to have kernel
calls which provide atomic operations. :-/

> On the roland/nptl branch there are a few nptl/ test failures in the
> sparc-linux build that don't show up in the sparcv9-linux build.  I presume
> those were preexisting problems and nobody was testing it or caring.

Those, I am pretty sure, were existing problems.

Thanks.