Re: Policy regarding linux-next only changes

[Tetsuo Handa]

On 2026/07/28 2:39, Mark Brown wrote:
>> For the latter example, syzbot is still using next-20260714 because a maintainer
>> who should accept/reject https://lkml.kernel.org/r/al1pElMQZsDfpAYI@michalis-linux
>> is not responding. As a result, syzbot is unable to test changes made between
>> next-20260714 and next-20260726.
> 
> This really just looks like another case where you (or someone) need to
> commuicate if something is urgent - I would have a hard time telling
> from that thread that there's a particularly big problem, the only reply
> indicating any kind of problem with the posted patch (from Joshua) was
> then followed up saying to disrgard it and there's nothing at all at any
> point in the thread or original report about the scope of the issue or
> any practical impact it's having.  Frankly I'm not clear that Michail
> (who posted the patch) is aware that there's any urgency here and isn't
> just acting reasonably and promptly on what was in the report mail.

This problem is caused by commit 860e748bddcc ("drm: ensure blend mode supported
if pixel format with alpha exposed") at
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit?id=860e748bddcc9291cbdd23e801640aeeba30cc44 .

That commit says "Drivers triggering this warning must be fixed.". That is,
they know that it is expected that WARN*() fires. But they don't know that
syzbot stops upon encountering "BUG:" or "WARNING:" within printk() output.

They also don't know that syzbot builds-in almost all modules into vmlinux.
That is, initialization functions of most modules are executed upon boot.
If one of modules emits "BUG:" or "WARNING:" line, the boot fails.

Maintainers sometimes apply commits that cause some in-tree modules to emit
"BUG:" or "WARNING:" line, without having grace period for confirming that
all in-tree modules are updated/fixed. Such decision is annoying for syzbot.

> 
> Even if someone were to click through the syzbot link the report is
> flagged as low priority in the dashboard and the config is just a link
> to a raw config so there's no indication if this is defconfig,
> randconfig or whatever.  There's absolutely nothing in the sysbot
> dashboard or list report that indicates to me that this has any kind of
> impact beyond "a warning is displayed during boot".

That priority is determined based on how critical the bug is (e.g. use-after-free write).
Therefore, being unable to build or boot is considered low priority because it can't cause
e.g. use-after-free write. However, the real impact of "being unable to build or boot" is
indicated at https://syzkaller.appspot.com/upstream/manager/ci-upstream-linux-next-kasan-gce-root .
Currently syzbot is failing to update linux-next kernels for two weeks due to
commit 860e748bddcc being in the linux-next tree.

All new bugs which are introduced while syzbot is unable to update linux-next kernels
are reported only after syzbot succeeded to update linux-next kernels. The "being unable
to build or boot" caused by addition of WARN*() can break whole testing by syzbot.