Re: Proposal: preflight checklist/lint for AI-assisted Linux kernel bug reports

On Fri, May 29, 2026 at 10:09:37PM +0900, mo to wrote:
> I understand that AI-assisted vulnerability and bug reports have
> recently become a burden for kernel maintainers, especially when
> reports are duplicated, unverified, or lack enough technical detail to
> be actionable.
> 
> I would like to suggest a lightweight “preflight” process for
> AI-assisted bug reports.
> 
> The goal is not to replace the existing Linux kernel email workflow,
> nor to move kernel development into a web-based ticket system.
> Instead, the idea is to add a simple validation layer before a report
> reaches maintainers.

This is generally along the lines of my suggestions here:
https://lore.kernel.org/ksummit/20260402-expert-maroon-partridge-f77f94@lemur/
(see under "new bug reporting")

I've done quite a bit of work on git-bug integration already, but I had to
step back to refocus on the infra again as we deal with upgrades, migrations,
and new kernel reboots. I hope to refocus on this work again soon.

> For AI-assisted reports, the submitter could be required to include a
> structured checklist such as:

I think if we *require* it, we'll never get any bug reports, because the
process of getting all of the below information is daunting even for someone
who deals with infrastructure all the time:

> - Kernel version:
> - Commit hash:

This is not easily established.

> - Architecture:
> - Kernel config:

They may not have access to it.

> - Affected subsystem / file / function:

That's often not obvious even for people who wrote the affected subsystem. ;)

> - Reproducer:

This may not be possible anyway, depending on the nature of the bug.

> - Reproduction rate:

This suggests a lot of effort spent on narrowing down the bug already.

> - Full dmesg / KASAN / UBSAN / lockdep / syzkaller log:

These are huge! Definitely not email attachment material -- we have to figure
out some place where we can store them, in a way that won't leak someone's
private info all over the place.

> - Checked latest mainline: yes/no
> - Checked stable trees: yes/no

It's pretty optimistic to think that the submitter will be willing to go that
far.

> - Checked lore.kernel.org for duplicates: yes/no

How would this even work? I'm in charge of lore.kernel.org and I'm not even
sure how I would check for bug duplicates without having to manually read
hundreds of entries.

> - Existing patch found: yes/no
> - Why this is considered a security issue:
> - Impact assessment:
> - Suggested fix or mitigation:

These usually happen late in the bug lifecycle and probably won't be relevant
at the start of the bug report process.

> - Human verification performed: yes/no
> 
> Reports that do not include basic information such as a tested commit,
> reproducer, full logs, duplicate search summary, and existing-patch
> check could be automatically rejected or redirected before maintainers
> spend time on them.

That would be awesome, but that would basically mean "zarro boogs" every time
you check. :)

-K