[PATCH v4 01/11] seq_buf: Do not print an empty line from an overflowed seq_buf_do_printk()

bot+bpf-ci at kernel.org bot+bpf-ci at kernel.org
Sat Oct 3 04:50:50 UTC 2026


> seq_buf: Do not print an empty line from an overflowed seq_buf_do_printk()

TL;DR: The new KUnit test may fail spuriously, and stop detecting the bug,
when console_loglevel suppresses KERN_INFO (quiet, loglevel=N) or
CONFIG_PRINTK=n, since the capture console never sees records.

> diff --git a/lib/tests/seq_buf_kunit.c b/lib/tests/seq_buf_kunit.c
> index eb466386bbef..0934dfb602ff 100644
> --- a/lib/tests/seq_buf_kunit.c
> +++ b/lib/tests/seq_buf_kunit.c

[ ... ]

> +static void seq_buf_printk_run(struct console *capture, struct seq_buf *s)
> +{
> +	seq_buf_printk_marked = 0;
> +	seq_buf_printk_empty = 0;
> +	seq_buf_printk_last_was_ours = false;
> +
> +	/*
> +	 * register_console() will not take an unmatched console without
> +	 * CON_ENABLED, and unregister_console() clears it, so set it on
> +	 * every run to keep the test repeatable.
> +	 */
> +	capture->flags = CON_ENABLED;
> +	register_console(capture);
> +	seq_buf_do_printk(s, KERN_INFO);
> +	unregister_console(capture);
> +}

Does this test depend on console_loglevel being above LOGLEVEL_INFO?

The records are printed at KERN_INFO, and a legacy console only gets a record
through console_emit_next_record(), which calls printk_get_next_message()
with may_suppress set.  That function skips any record for which
suppress_message_printing() is true:

    static bool suppress_message_printing(int level)
    {
            return (level >= console_loglevel && !ignore_loglevel);
    }

A skipped record just advances con->seq and ->write() is never called.

With console_loglevel <= 6, seq_buf_printk_capture() never runs and
seq_buf_printk_marked stays 0, so these expectations in
seq_buf_do_printk_test() fail:

    KUNIT_EXPECT_EQ(test, seq_buf_printk_marked, 1);
    KUNIT_EXPECT_EQ(test, seq_buf_printk_marked, 2);
    KUNIT_EXPECT_EQ(test, seq_buf_printk_marked, 1);

The seq_buf_printk_empty checks would still pass in that setup, so the test
would also stop detecting the bug it was written for.

CONFIG_CONSOLE_LOGLEVEL_QUIET is 4 when "quiet" is on the command line.  A
loglevel=N boot argument, dmesg -n, or a kernel.printk sysctl that lowers the
console level has the same effect, and some distributions lower it by
default.  With CONFIG_SEQ_BUF_KUNIT_TEST=m this would report a failure.  The
same happens with CONFIG_PRINTK=n, where printk() is a no-op and
SEQ_BUF_KUNIT_TEST depends only on KUNIT.

The kunit.py qemu and UML runs would not notice, since they do not lower the
loglevel.  The later commits in this series still call
seq_buf_do_printk(s, KERN_INFO) unchanged.

Would it make sense to use a level that is not filtered, call kunit_skip()
when console_loglevel would suppress KERN_INFO, or read the records back from
the printk ring buffer instead of a console?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/37096036516


More information about the Linux-security-module-archive mailing list