Re: Seeking input on beginner-level bugs related to preempt_RT

["John B. Wyatt IV" <jwyatt@redhat.com>]

On Fri, Apr 12, 2024 at 05:00:39PM -0600, Miguel Miranda wrote:
> Hello everyone,
> 

Welcome.

> I am currently looking for beginner-level bugs related to preempt_RT for the
> Linux kernel Bug Fixing Spring Unpaid 2024.

What is your experience level? Have you built and run an rt kernel
before? (Selected Fully Preemptive in kconfig?)

> Although I am not an expert in
> RT, I have been trying to identify some bugs and our mentors have suggested
> using ring testers such as syzkaller and test frameworks like
> kernelselftests to find and reproduce these bugs on our own.

A lot of the bugs we encounter are around locking. RT changes
the way locks are handled in the kernel. That is one avenue I would
encourage you to study.

Not sure if anyone has actually used syzkaller on the preempt-rt
patchset. Never used it before, but I would be interested in it's
results.

You can read about kselftests here:

https://elixir.bootlin.com/linux/latest/source/Documentation/dev-tools/kselftest.rst

> 
> I have a few questions and would appreciate any input you may have. Firstly,
> is there a specific CI ring or channel that lists KTODOs, or a preferred
> platform where bugs related to PREEMPT_RT are reported? Secondly, I have
> been following the LKML and have seen some console_blast.sh results, but I
> am not sure where to find this console_blast. Lastly, I have come across
> some recent discussions about printk() related work, but I'm unsure if there
> is a list to avoid rework.

John Ogness sent me that script and I posted in another email on this
list. I forget which one.

John specifically asked for a very large core machine to do the testing
on with a uart 8250 interface. That might be difficult for you to
procure but I have included it below. Please make sure to use the
correct line endings or Bash will not like it. :)

#!/bin/sh
set -e

# This script is intended to be started with no arguments.
#
# It then calls itself to create a pinned process for each CPU. Those
# child processes will run in infinite loops of show-task-states via
# /proc/sysrq-trigger. This generates lots of contention on the console.
#
# Finally, it waits 10 seconds before crashing the system.

if [ $# -eq 0 ]; then
	cpus=$(($(nproc) - 1))
	for i in $(seq 0 $cpus); do
		$0 $i &
	done

	sleep 15
	echo c > /proc/sysrq-trigger
	exit 0
fi

# Setup the CPU mask for the provided CPU number. The real taskset(1)
# could simply use -c, but the busybox(1) variant does not support this.
mask=$(printf "0x%x\n" $((1 << $1)))
taskset -p $mask $$

# Wait a moment before beginning blast.
sleep 2

while true; do
	echo t > /proc/sysrq-trigger
done


-- 
Sincerely,
John Wyatt
Software Engineer, Core Kernel
Red Hat