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