The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: "Theodore Tso" <tytso@mit.edu>
To: Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>
Cc: Alexander Potapenko <glider@google.com>,
	Mark Brown <broonie@kernel.org>,
	Christoph Hellwig <hch@infradead.org>,
	Aleksandr Nogikh <nogikh@google.com>,
	Boqun Feng <boqun@kernel.org>, Gary Guo <gary@garyguo.net>,
	linux-next@vger.kernel.org, linux-kernel@vger.kernel.org,
	Miguel Ojeda <ojeda@kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	peterz@infradead.org, will@kernel.org, longman@redhat.com,
	mingo@kernel.org, gregkh@linuxfoundation.org,
	Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
Subject: Re: Policy regarding linux-next only changes
Date: Fri, 24 Jul 2026 17:05:16 -0400	[thread overview]
Message-ID: <amPGflb7w6RcOO1M@mit.edu> (raw)
In-Reply-To: <7250a5ad-ec2d-4852-af56-9c1c653d24c7@I-love.SAKURA.ne.jp>

On Sat, Jul 25, 2026 at 12:29:27AM -0500, Tetsuo Handa wrote:
> The problem is that a maintainer who has the permission to
> accept/reject patches tends to become defunctional when syzbot is
> involved. What actions can the Linux kernel community take in order
> to address this problem (instead of just ignoring developers who are
> trying to fix bugs)?

Fundamentally, not all bugs are worth fixing.  And if you believe that
all bugs are worth fixing, you need to convince companies to **fund**
that work, and not leave it as unfunded mandate.  If you give me some
minions who can be dedicated to help fix bugs, I'm certainly willing
to provide technical direction.  But there's no such thing as a free
lunch --- and the business case is not as clear cut as you seem to be
assuming.

In essence, this is a cost allocation problem.  When you ask for help
from other maintainers to fix something that you care about, if it's
not important to them or their company / management chain, you are
dumping costs from you to them.  This can work if you can also help
them in turn in other areas.  This happens all the time, actually, and
it's what makes Open Source work.

So I think the way we solve this problem is by finding ways to
allocate the costs to those companies or organizations that think it
is a good fit for their business, and to reduce the burden on those
whose company (or management chain) doesn't think the business case is
sufficiently compelling.

Other solutions might include finding some AI solution which can
filter the low-priority quality Syzbot reports from the high-quality
ones.  If some companies or some departments may have different
priorities, perhaps they can use different filuters, so they can work
on those bugs that they think are important.

Perhaps AI's can do a better job at proposing some patches that
resolve the problem, or creating reliable reproducers that don't
require thousands of VM hours of testing.

One of the reasons why I am personally more supportive about Sashiko
than syzbot is because Sashiko is a technology which is reducing *my*
workload.  It does transfer more work to the contributor, but if they
are trying to get code into the kernel and if their company think
there is a business case for that new feature, it seems right that we
require that pay the development costs of submitting high-quality
code.

Cheeres,

					- Ted

  reply	other threads:[~2026-07-24 21:17 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-02 11:49 Policy regarding linux-next only changes Gary Guo
2026-07-02 12:49 ` Tetsuo Handa
2026-07-02 13:37   ` Miguel Ojeda
2026-07-02 14:11   ` Boqun Feng
2026-07-04 10:14     ` Tetsuo Handa
2026-07-04 12:06       ` Miguel Ojeda
2026-07-04 13:22         ` Theodore Tso
2026-07-05 11:36           ` Tetsuo Handa
2026-07-05 12:02             ` Miguel Ojeda
2026-07-05 12:06               ` Miguel Ojeda
2026-07-05 12:20               ` Mark Brown
2026-07-05 12:06         ` Mark Brown
2026-07-05 14:16           ` Tetsuo Handa
2026-07-06 17:23             ` Mark Brown
2026-07-20 10:06         ` Tetsuo Handa
2026-07-21  9:38           ` Alexander Potapenko
2026-07-21 11:48             ` Tetsuo Handa
2026-07-22 14:19               ` Alexander Potapenko
2026-07-22 15:07                 ` Tetsuo Handa
2026-07-22 17:47                   ` Theodore Tso
2026-07-24 12:11                     ` Tetsuo Handa
2026-07-24 13:50                       ` Theodore Tso
2026-07-24 14:35                         ` Tetsuo Handa
2026-07-24 14:51                           ` Theodore Tso
2026-07-24 15:29                             ` Tetsuo Handa
2026-07-24 21:05                               ` Theodore Tso [this message]
2026-07-24 17:49                           ` Miguel Ojeda
2026-07-05  9:05       ` [PATCH] lockdep: Enable the printing of held locks of running non-current tasks (was: Policy regarding linux-next only changes) Ingo Molnar
2026-07-05 11:05         ` [PATCH] lockdep: Enable the printing of held locks of running non-current tasks Tetsuo Handa
2026-07-07  7:20           ` [PATCH -v2] lockdep: Enable the printing of held locks of remote running tasks and print task CPU Ingo Molnar
2026-07-07 13:10             ` Tetsuo Handa
2026-07-08  8:37               ` Ingo Molnar
2026-07-07  7:21         ` [tip: locking/debug] " tip-bot2 for Ingo Molnar
2026-07-08  8:41         ` [tip: locking/core] " tip-bot2 for Ingo Molnar
2026-07-05 14:59       ` Policy regarding linux-next only changes Boqun Feng
2026-07-02 13:22 ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=amPGflb7w6RcOO1M@mit.edu \
    --to=tytso@mit.edu \
    --cc=boqun@kernel.org \
    --cc=broonie@kernel.org \
    --cc=gary@garyguo.net \
    --cc=glider@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=miguel.ojeda.sandonis@gmail.com \
    --cc=mingo@kernel.org \
    --cc=nogikh@google.com \
    --cc=ojeda@kernel.org \
    --cc=penguin-kernel@i-love.sakura.ne.jp \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox