Re: [PATCH 4/5] vfio: selftests: Add sysfs_kernel_warn_count_get()

["David Matlack" <dmatlack@google.com>]

On Tue Nov 10, 2026 at 9:34 AM PST, Alex Williamson wrote:
> On Thu, 29 Oct 2026 20:33:23 +0000
> David Matlack <dmatlack@google.com> wrote:
>
>> Add a helper to read /sys/kernel/warn_count, which counts the number of
>> warnings (e.g. WARN(), KASAN, and UBSAN reports) the kernel has
>> encountered since boot. Return a negative value if the file does not
>> exist, e.g. on kernels that predate it.
>> 
>> Factor the code to read an integer from a sysfs file out of
>> sysfs_val_get_int() so that it can be shared by both helpers.
>> 
>> This will be used in a subsequent commit to detect kernel warnings
>> triggered by tests.
>> 
>> Signed-off-by: David Matlack <dmatlack@google.com>
>> ---
>>  .../vfio/lib/include/libvfio/sysfs.h          |  7 +++++++
>>  tools/testing/selftests/vfio/lib/sysfs.c      | 19 +++++++++++++++----
>>  2 files changed, 22 insertions(+), 4 deletions(-)
>
> I have a concern with this approach.  I run selftests in parallel as
> much as possible, using multiple devices, each targeted at specific
> tests, with other functional and performance tests running
> concurrently.  When wiring this into my harness, I initially saw a
> failure, but can't reproduce and have no log from the original event.
>
> I've updated my local CI to keep a console log so that I might have a
> chance of chasing the next instance, but I don't much like the fact
> that any warning occurring concurrently with this test can trigger a
> failure and the test doesn't provide anything to go on in the test logs
> themselves.  Thanks,

Thanks for trying this out and the report.

What do you think about keeping warn_count to detect warnings, but also
reading /dev/kmsg so the failure details are captured?

 - In setup, record warn_count and open /dev/kmsg and seek to the end.

 - In teardown, if warn_count changed, read the new /dev/kmsg records
   and print the kernel warning reports (WARNING:, BUG:, KASAN, UBSAN,
   etc.), including their call traces, into the test log before
   failing.

That way, if the check fails, the test log would show exactly what
fired and you could tell right away whether it came from VFIO or from
something else running concurrently.

To avoid breaking setups like yours that run lots of tests in
parallel, we could also make failing on warnings opt-in via an
environment variable, so by default the test only logs the reports.

Alternatively we could just say warn checking should be up to the user.