Re: [PATCH] parisc: Fix extraction of hash lock bits in syscall.S

[John David Anglin <dave.anglin@bell.net>]

On 2021-11-18 2:24 p.m., Helge Deller wrote:
> On 11/18/21 18:03, John David Anglin wrote:
>> The extru instruction leaves the most significant 32 bits of the target register in an undefined
>> state on PA 2.0 systems.  If any of these bits are nonzero, this will break the calculation of the
>> lock pointer.
>>
>> Fix by using extrd,u instruction on 64-bit kernels.
> Good catch!!
> Did you checked if it actually happened that the most
> significant 32 bits were non-zero?
No.  I tend to think the bits are always zero but the arch says they are undefined.
> If so, could this be one of the reasons we saw strange
> issues or even memory corruption?
Possibly but I wouldn't be too hopeful that it will make a big difference.
>
> Sadly I sent a pull request to Linus a few hours ago,
> otherwise I would have added this patch...
I just noticed the problem yesterday.  I was looking at the failure of glibc's tst-cleanupx4:

dave@mx3210:~/gnu/glibc/objdir$ env GCONV_PATH=/home/dave/gnu/glibc/objdir/iconvdata LOCPATH=/home/dave/gnu/glibc/objdir/localedata LC_ALL=C 
/home/dave/gnu/glibc/objdir/elf/ld.so.1 --library-path 
/home/dave/gnu/glibc/objdir:/home/dave/gnu/glibc/objdir/math:/home/dave/gnu/glibc/objdir/elf:/home/dave/gnu/glibc/objdir/dlfcn:/home/dave/gnu/glibc/objdir/nss:/home/dave/gnu/glibc/objdir/nis:/home/dave/gnu/glibc/objdir/rt:/home/dave/gnu/glibc/objdir/resolv:/home/dave/gnu/glibc/objdir/mathvec:/home/dave/gnu/glibc/objdir/support:/home/dave/gnu/glibc/objdir/crypt:/home/dave/gnu/glibc/objdir/nptl 
/home/dave/gnu/glibc/objdir/nptl/tst-cleanupx4
test 0
clh (2)
clh (1)
clh (3)
global = 12, expected 15
[...]

As far as I can tell, clh() is called in the wrong order - should be 1, 2, 3.  This gives the expected value of 15.  2, 1, 3 yields 12.

This suggests our atomic operations are broken.  I think the problem may be that atomic loads may need to be sequenced
with the LWS lock.  While sequencing stores is obvious, this is not obvious for loads.  Anyway, I starting hacking on syscall.S
to provide lws_atomic_load and lws_atomic_store operations. Currently, atomic stores are done using CAS operation.  This
is less efficient than it could be.

Another little issue is "because" is misspelled in a couple of places in syscall.S.

Dave

-- 
John David Anglin  dave.anglin@bell.net