Re: Policy regarding linux-next only changes

["Theodore Tso" <tytso@mit.edu>]

On Fri, Jul 24, 2026 at 11:35:36PM -0500, Tetsuo Handa wrote:
> I wonder whether it is appropriate to call "syzbot issues". syzbot is
> finding bugs in upstream git trees. Unless the cause of a bug is either
> syzbot is doing a stupid thing or compiler/toolchain is broken, it is
> "an upstream kernel issue".

I know that people have different experiences of Syzbot reported
issues, but the bugs I see require root privileges, modifying a file
system while it is mounted, maliciously corrupting file system images
and then mounting it without first running fsck, mucking with the loop
device (which requires root privileges) while it is in use by a file
system.

I do agree that if you mount a file system without running fsck, and
it has been maliciously corrupted, it woud be nice(tm) if it didn't
result in a crash or a WARN_ON.  If someone wants to fund the
engineering work to make this be true, so long as it doesn't
compromise long-term code maintainability or performance, patches
would be welcome.  So perhaps this is a P2 bug.  But it's not
something I'm going to consider high priority, because it's not in any
threat model that I or the people who manage the budget and head count
authorizations, care about.

Since that's the *vast* majority of the issues reported by syzbot, I
tend to use "syzbot bug" as a shorthand.

I can't speak to whether the syzbot bugs you are chasing fall into
this category or not.  But if it requires *vast* amount of VM time, it
makes me suspect that it falls into that category.

> Those who hate my attempts (i.e. sending patches to linux-next without
> being reviewed/acked by maintainers) are expecting that any patch is
> reviewed/acked by maintainers. But some maintainers are considering bugs
> reported by syzbot as "not worth looking into". Therefore, not only
> debug printk() patches (for bugs found by syzbot) but also bug fix patches
> (which syzbot has found) are getting ignored.

Yep, and I've explained above why that's the case.  I've tried to make
the case that if there was a way that we could easily separate out
those bugs which are signal from noise (at leat as defined by those
people who refuse to fund this development work), it might be good for
improving syzbot's reputation.  But I'm so busy that I don't have time
to go through all of the syzbot reported issues to see if any of them
are actually ones that should be considered high priority.

> In other words, the interest (by the upstream Linux kernel community) on
> fixing kernel bugs which syzbot found are decreasing. This is a deadlock
> situation, and just saying "Not my business." is not helpful.

Perhaps if Syzbot could be improved so we can be more selective about
which bugs are worth fixing, it might actually be better for the
kernel's quality.

But if the goal is to get ourselves to zero bugs, or zero syzbot
reported issues, that's not a goal I can get behind.  It certainly
isn't something my management chain isn't willing to support that
goal, and it's NOT going to happen out of my own personal time.

Cheers,

					- Ted