[PATCH] nptl: Add <thread_pointer.h> for or1k

[Stafford Horne]

On Tue, Dec 24, 2024 at 08:20:00PM +0000, Stafford Horne wrote:
> On Sat, Dec 14, 2024 at 11:03:27AM +0000, Stafford Horne wrote:
> > +CC Lists,
> > 
> > They should have been included for all of these.
> > 
> > On Fri, Dec 13, 2024 at 11:22:32AM -0500, Michael Jeanson wrote:
> > > On 2024-12-12 07:41, Stafford Horne wrote:
> > > > On Tue, Dec 10, 2024 at 03:30:05PM -0500, Michael Jeanson wrote:
> > > >> On 2024-12-10 13:56, Michael Jeanson wrote:
> > > >>>> I started adding rseq support to OpenRISC, but it seems I need to do a bit more
> > > >>>> for me than just call rseq_signal_deliver().  OpenRISC does not implement
> > > >>>> HAVE_REGS_AND_STACK_ACCESS_API yet, so I will need to do that first.  Also I
> > > >>>> need to think of an instruction to use for RSEQ_SIG, but that should not be too
> > > >>>> hard.
> > > >>>
> > > >>> Do you have a WIP tree somewhere I can have a look at? Assuming you add
> > > >>> HAVE_REGS_AND_STACK_ACCESS_API, the rest should be pretty simple.
> > > >>
> > > >> I had a quick look at the kernel code and it looks pretty straightforward,
> > > >> I hacked this together just to see if it would build :
> > > >>
> > > >>   https://github.com/mjeanson/linux/commits/openrisc-rseq/
> > > >>
> > > >> This is thoroughly untested and only cross-compiled.
> > > > 
> > > > Thanks, while you were doing this I did something similar but took a much
> > > > shorter route, I only implemented the APIs used by rseq.
> > > > 
> > > > I have pushed branches for linux and glibc here:
> > > > 
> > > >  - https://github.com/stffrdhrn/or1k-glibc/commits/or1k-rseq/
> > > >  - https://github.com/stffrdhrn/linux/commits/or1k-rseq/
> > > 
> > > You might also want to add a call to 'rseq_syscall' in arch/openrisc/kernel/entry.S
> > > on return to userspace when CONFIG_DEBUG_RSEQ is enabled.
> > 
> > Yes, I am aware of that one, but I think I discovered an issue with the return to
> > userspace code that needs some cleanup before I can add that in.
> 
> I think this ended up being ok.
> 
> I have added the call to rseq_syscall and implemented self tests on my branch
> now.
> 
>  - https://github.com/stffrdhrn/linux/commits/or1k-rseq/
>  - commit 1fa73dd6c2d3 ("rseq/selftests: Add support for OpenRISC")
> 
> I haven't got the tests to complete fully yet though.  Do you have a recommended
> approach for building, testing and debugging them?  I am using my glibc
> toolchain, but I assume the original implementations didnt have glibc support
> available when they were testing.
> 
> My stack now:
> 
>   - QEMU virt
>   - Linux virt_defconfig (or1k-rseq branch)
>     - rseq selftests - built with gcc/glibc toolchain (or1k-rseq branch)
>   - rootfs - Buildroot with my glibc (or1k-rseq branch)
>     - gdb
>     - strace
> 
> In general I am using the latest git HEADs for qemu, gcc, binutils etc.
> 
> Once, everything is working on QEMU I will test again on the FPGA hardware.
> 
> Currently tests are failing with SIGSEGV:
> 
>     TAP version 13
>     1..10
>     # timeout set to 0
>     # selftests: rseq: basic_test
>     # testing current cpu
>     ok 1 selftests: rseq: basic_test
>     # timeout set to 0
>     # selftests: rseq: basic_percpu_ops_test
>     # spinlock
>     # ./kselftest/runner.sh: line 37:   772 Segmentation fault      /usr/bin/timeout  --foreground "$kselftest_timeout" /usr/bin/timeout "$kselftest_timeout" $1
>     not ok 2 selftests: rseq: basic_percpu_ops_test # exit=139
> 
> In gdb it looks to be happening in in an mprotect syscall in glibc and at that
> point the stack seems to be corrupt already.  So its taking me a bit of time to
> untangle.

I was able to get this fixed, the issue was with how I was setting up the
rseq_cs in rseq-or1k.h.  There were some other problems too which I fixed.

Now, some of the tests are passing.

I have been making progress with some kernel printk's in kernel/rseq.c and using
gdb.  I should be able to get the remaining issues fixed up before too long.

-Stafford