Re: Policy regarding linux-next only changes

[Leandro Ribeiro <leandro.ribeiro@collabora.com>]

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
>> <penguin-kernel@i-love.sakura.ne.jp> 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/5b2dea50-2850-4876-b6e8-ba94b9a85034@I-love.SAKURA.ne.jp :
> 
>   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