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

[Stafford Horne <shorne@gmail.com>]

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.

-Stafford