Re: Policy regarding linux-next only changes
Leandro Ribeiro <[email protected]> Wed, 29 Jul 2026 09:48:22 -0300
| Newsgroups | org.kernel.vger.linux-next,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 7/28/26 20:46, Tetsuo Handa wrote: > On 2026/07/29 7:11, Miguel Ojeda wrote: >> On Tue, Jul 28, 2026 at 4:46 PM Tetsuo Handa >> <[email protected]> wrote: >>> >>> syzbot stops upon encountering "BUG:" or "WARNING:" within printk() output. >> >> Out of curiosity, is that a fundamental property or something that >> could be optionally be relaxed (for certain linux-next runs only, >> perhaps) so that you can continue testing in certain cases where the >> "WARNING:" may be harmless (i.e. irrelevant for your particular >> fuzzing)? >> >> i.e. I was wondering whether the system could ignore the "WARNING:"s >> (and avoid the kernel panicking on them etc.) until after boot, i.e. >> when the fuzzing starts. > > syzbot uses kernel.panic_on_warn=1, for most of WARN*() users are reporting > problems that should not be ignored. Therefore, WARN*() must not be used for > reporting recoverable mistakes like -EINVAL. Abusing WARN*() like > https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/kernel/workqueue.c?id=6e845bcb78c95af935094040bd4edc3c2b6dd784#n5855 > is a fatal barrier for continuous testing systems like syzbot. > > Quoting from https://lkml.kernel.org/r/[email protected] : > > Please never try to emit WARNING: or BUG: message just for letting developers > update their code. If you can't use panic() instead of WARN*() or BUG*(), you > should not use WARN*() or BUG*(). The patch author who changes the behavior of > in-tree code is responsible for updating all in-tree code. > > Commit 860e748bddcc ("drm: ensure blend mode supported if pixel format > with alpha exposed") must be reverted or updated not to emit "WARNING:" string. > Until authors of that commit respond, that commit had better be excluded from > the linux-next tree. > Hello, First of all, sorry for all the trouble with this warning. I'll propose a patch replacing the warning with printk() or pr_info(), if that doesn't cause similar issues for fuzzers. Thanks, Leandro