Skip to content

Conversation

bmastbergen
Copy link
Collaborator

This is a helper script for running kselftests against a kernel under test. It attempts to install the appropriate dependencies for different versions of Rocky Linux and attempts to run appropriate tests, with appropriate permissions, for a few select kernel versions.

This is just a starting point. Hopefully this continues to evolve, increasing the number of successful that can reliably be run.

Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR adds a comprehensive helper script for running kernel self-tests (kselftests) against different kernel versions on Rocky Linux systems. The script automates dependency installation and test execution with appropriate permissions.

  • Implements version-specific dependency installation for Rocky Linux 8, 9, and 10
  • Provides kernel version-specific test configurations with different target sets and skip lists
  • Includes automated test execution with both regular and sudo permissions for different test categories

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

@ciq-it-service-account
Copy link

ciq-it-service-account commented Sep 30, 2025

🎉 Snyk checks have passed. No issues have been found so far.

code/snyk check is complete. No issues have been found. (View Details)

Copy link

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 6 comments.


Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

@bmastbergen bmastbergen force-pushed the kernel_kselftest branch 3 times, most recently from 937c383 to ea2fbeb Compare September 30, 2025 17:05
This is a helper script for running kselftests against a kernel
under test.  It attempts to install the appropriate dependencies
for different versions of Rocky Linux and attempts to run appropriate
tests, with appropriate permissions, for a few select kernel versions.

This is just a starting point.  Hopefully this continues to evolve,
increasing the number of successful that can reliably be run.
@roxanan1996
Copy link
Contributor

Minor question: do we need to add a Signed-off -by for all commits? Or is it just for the kernel sources?
Personally, I am so used to checking Signed-off-by everywhere, so I would encourage people to use it everywhere.
This can be achieved by using git commit -s.

@bmastbergen
Copy link
Collaborator Author

Minor question: do we need to add a Signed-off -by for all commits? Or is it just for the kernel sources? Personally, I am so used to checking Signed-off-by everywhere, so I would encourage people to use it everywhere. This can be achieved by using git commit -s.

No, we haven't stipulated sign-offs for any repos other than the kernel. Certainly doesn't hurt though.

*)
echo
echo "Warning: Unknown kernel version ($(uname -r)). No kselftest targets defined."
echo "SUDO_TARGETS and SKIP_TARGETS will be empty."
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, I would exit here. Because otherwise it will run the kselftests for an unknown version.

I would imagine we run into this if we test a new kernel. So an early exit would catch this and then the person running this would add a case here for the new kernel version. Otherwise the kselftests would run and this warning may be missed.

What do you think?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea, I almost made it exit here. I could go either way.

make -C tools/testing/selftests clean
make -C tools/testing/selftests SKIP_TARGETS="$SKIP_TARGETS"
for run in $(seq 1 $runs) ; do
make -C tools/testing/selftests SKIP_TARGETS="$SUDO_TARGETS $SKIP_TARGETS" run_tests | tee ~/selftest-$(uname -r)-$run.log
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

~/selftest-$(uname -r)-$run.log does not work for me. And I believe it would be a bit hard to differentiate between logs if we save all of them in the same place, even though we do include the version in the name.

The folder structure for each vm (kernel type) I have is:

kernel-dist-git
kernel-src-tree
kernel-src-tree-tools -> /home/rnicolescu/ciq/kernel-src-tree-tools
kernel-tools -> /home/rnicolescu/ciq/kernel-tools
build-logs
kselftests-logs

So for me ../kselftests-logs/selftest-$(uname -r)-$run.log would work. Or something similar, happy to adjust it.

We can also add a param for this, but I would keep it simple. I think it would be super easier for our tooling if we all have the same tree structure for kernels.
What do you think?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yea, ../kselftests-logs makes sense. or....err... ../kselftest-logs I never know whether to use kselftest or kselftests

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am also bad at naming. Pick one and stick with it :)

SKIP_TARGETS=$2
make -C tools/testing/selftests clean
make -C tools/testing/selftests SKIP_TARGETS="$SKIP_TARGETS"
for run in $(seq 1 $runs) ; do
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yesterday I triggered another run by mistake and I wish I saved the previous log.
If you also think it's valuable, I would check if a file with the same name exists and adjust the run var accordingly.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

or maybe timestamping logs makes more sense than numbering?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Either way, I will not know easily which one is which if they have long names. Not sure here which one is the best at the moment. Maybe this is over engineering at the moment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants