Re: [PATCH v5 7/9] rv: Replace tss and sncid monitors with more complete sts

[Nam Cao <namcao@linutronix.de>]

On Tue, Jul 29, 2025 at 11:25:12AM +0200, Nam Cao wrote:
> On Tue, Jul 29, 2025 at 10:46:51AM +0200, Gabriele Monaco wrote:
> > On Mon, 2025-07-28 at 17:53 +0200, Nam Cao wrote:
> > > I gave this a try on riscv64 and observed some errors:
> > > 
> > > [  620.696055] rv: monitor sts does not allow event sched_switch on
> > > state enable_to_exit
> > > [  621.047705] rv: monitor sts does not allow event sched_switch on
> > > state enable_to_exit
> > > [  642.440209] rv: monitor sts does not allow event sched_switch on
> > > state enable_to_exit
> > > 
> > > I tested with two user programs:
> > > 
> > >     int main() { asm ("unimp"); }
> > >     int main() { asm ("ebreak"); }
> > > 
> > > The two programs are repeatedly executed:
> > > 
> > >     #!/bin/bash
> > >     ./test1 &
> > >     ./test2 &
> > >     # ... repeat lots of time
> > > 
> > > Any idea?
> > 
> > Mmh I see what you're doing here..
> > Those instructions are supposed to raise some sort of exception in the
> > CPU which apparently disables and enables interrupts without raising an
> > interrupt handler tracepoint (the discriminator for this monitor).
> > This lets the monitor believe we passed the time a switch is possible
> > and complain when it actually sees one.
> > 
> > I still couldn't reproduce it on my VM, yet I find the timing a bit
> > strange: it's alright we handle the illegal instruction like this, but
> > do we really end up doing that while scheduling although it doesn't
> > look like an interrupt?!
> > 
> > Could you share a bit more about your riscv setup? It might some
> > configuration/hardware specific thing.
> 
> Kernel:
>   - base: ftrace/for-next
>   - config: defconfig + mod2noconfig + PREEMPT_RT + monitors
> 
> Hardware:
> 	qemu-system-riscv64 -machine virt \
> 	-kernel ../linux/arch/riscv/boot/Image \
> 	-append "console=ttyS0 root=/dev/vda rw" \
> 	-nographic \
> 	-drive if=virtio,format=raw,file=riscv64.img \
> 	-smp 4 -m 4G
> 
> 	riscv64.img is a Debian trixie image from debootstrap
> 
> Test:
> 	echo 0 > /proc/sys/debug/exception-trace
> 	./testall # see attached

I should note that this takes a few tries before something shows up.

Below is the backtrace, in case it helps:

illegal    3246 [000]  1020.132675: rv:error_sts: event sched_switch not expected in the state enable_to_exit
        ffffffff8013231c __traceiter_error_sts+0x28 ([kernel.kallsyms])
        ffffffff8013231c __traceiter_error_sts+0x28 ([kernel.kallsyms])
        ffffffff80138aa4 da_event_sts+0x198 ([kernel.kallsyms])
        ffffffff80138cf0 handle_sched_switch+0x46 ([kernel.kallsyms])
        ffffffff80aaf222 __schedule+0x4ba ([kernel.kallsyms])
        ffffffff80aafb80 preempt_schedule_irq+0x32 ([kernel.kallsyms])
        ffffffff80aac714 irqentry_exit+0x76 ([kernel.kallsyms])
        ffffffff80aac1dc do_irq+0x38 ([kernel.kallsyms])
        ffffffff80ab7da6 __lock_text_end+0x12e ([kernel.kallsyms])
        ffffffff80a93e50 mas_find+0x0 ([kernel.kallsyms])
        ffffffff8021ea60 vms_clear_ptes+0xe8 ([kernel.kallsyms])
        ffffffff8021f81a vms_complete_munmap_vmas+0x58 ([kernel.kallsyms])
        ffffffff80220706 do_vmi_align_munmap+0x15c ([kernel.kallsyms])
        ffffffff802207d0 do_vmi_munmap+0xa6 ([kernel.kallsyms])
        ffffffff80221f3c __vm_munmap+0xa2 ([kernel.kallsyms])
        ffffffff8020be7c vm_munmap+0xe ([kernel.kallsyms])
        ffffffff802bbdbe elf_load+0x14c ([kernel.kallsyms])
        ffffffff802bc1f4 load_elf_binary+0x36e ([kernel.kallsyms])
        ffffffff80264426 bprm_execve+0x254 ([kernel.kallsyms])
        ffffffff8026570c do_execveat_common.isra.0+0x11e ([kernel.kallsyms])
        ffffffff802664de __riscv_sys_execve+0x32 ([kernel.kallsyms])
        ffffffff80aabf84 do_trap_ecall_u+0x1bc ([kernel.kallsyms])
        ffffffff80ab7dc8 __lock_text_end+0x150 ([kernel.kallsyms])