Re: Policy regarding linux-next only changes

On 2026/07/30 7:57, Miguel Ojeda wrote:
> On Thu, Jul 30, 2026 at 12:03 AM Tetsuo Handa
> <[email protected]> wrote:
>>
>> That does not help. syzbot stops not because the kernel calls panic()
>> but because the kernel emits "WARNING:" etc. followed by a stack trace.
>> The list of patterns is at
>> https://github.com/google/syzkaller/blob/master/pkg/report/linux.go .
> 
> The point is that syzbot could skip those until a given point at boot.
> But in order to do that, of course, you still need to disable the
> panicking.

Suppose syzbot defers evaluation of

  ------------[ cut here ]------------
  [PLANE:35:plane-0] pixel format with alpha exposed but blend mode not setup
  WARNING: drivers/gpu/drm/drm_mode_config.c:873 at validate_blend_mode_for_alpha_formats drivers/gpu/drm/drm_mode_config.c:872 [inline], CPU#1: swapper/0/1
  WARNING: drivers/gpu/drm/drm_mode_config.c:873 at drm_mode_config_validate+0x1c6a/0x1e60 drivers/gpu/drm/drm_mode_config.c:938, CPU#1: swapper/0/1
  (...snipped...)

messages until a given point at boot, how can syzbot determine whether it is
appropriate to start (or continue) fuzz testing? This specific WARNING: is
harmless but almost all other WARNING: indicates something is wrong (e.g. the
kernel's state might be no longer consistent), like panic_on_warn is there.
Deferring could mitigate "being unable to follow daily next-YYYYMMDD" problem, but
it can force syzbot to fuzz-test on already broken kernels (adds a new problem).

If a Gen-AI is used while running syzkaller and that AI is capable of evaluating
whether it is appropriate to start (or continue) fuzz testing when encountering
individual WARNING: messages, syzkaller could skip this specific WARNING: as
harmless. But unlike Sashiko, syzkaller itself is not meant to require GPU for
running AI models when the kernel to be fuzz-tested is running.



I feel that the discussion is getting out of the point. Like I explained at
https://lkml.kernel.org/r/[email protected] ,
the point of this discussion is how to address the technical problem and the
procedural problem. For the former, I will start a new thread. But for the latter,
I sent "[PATCH v5] loop: Fix NULL pointer dereference in lo_rw_aio()" to ML but got
no responses / interests from developers / maintainers. This bug remains undebuggable
if you don't want me to send this patch to linux-next tree via my tree while saying
"Not my business.".