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@xxxxxxxx
