Re: Policy regarding linux-next only changes

[Tetsuo Handa]

On 2026/07/25 6:05, Theodore Tso wrote:
> 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.

Have you ever seen https://syzkaller.appspot.com/upstream/syz-dungeon which
ranks contributors (kernel developers) based on their achievements in fixing
bugs found by Syzkaller? You can find that I am the second top contributor.

Also, my activity for fixing bugs found by syzbot is not my $WORK. I am working
on those bugs using my private time. I am neither working at Google-related
companies nor a member of syzbot team (who can change kernel config for syzbot
kernels in order to help syzbot continue testing).

> 
> 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.

That is wrong. I make not only debug printk() patches but also bug-fix patches.
I am asking for approval from maintainers to fix bugs that syzbot found.
It is really annoying that maintainers keep silence for unknown reason
(maybe they are thinking that "I don't care about this bug"). I can't make
forward progress if maintainers keep silence. What are the maintainers for?

At the panel discussion in LinuxCon Europe 2011, Linus Torvalds has said
"the average age at the summit has risen by one year every year"
( https://lwn.net/Articles/464530/ ). If maintainers are there to let
developer's effort be sent to /dev/null, trying to contribute is waste of time
and new developers won't grow up.

> 
> 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.

Not all developers have enough money to pay to companies/organizations.
Some developers (including me) are contributing by spending their time
instead of paying money.

Your statements sound like "Poor men/women cannot participate into the Linux
kernel development." Please don't assume that everything is controlled by
"who pays the money?".

> 
> 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.

syzbot already has a priority filter. But trying to make patches based on
that filter will result in a waste of time if maintainers are not responding.

Please respond to syzbot-related patches. For example, if you are not
interested in a bug syzbot has reported, respond to that report like

  "I do not think that this bug is important enough to fix. Therefore,
   I won't give you Reveiwed-by: nor Acked-by: even if you propose a patch."

. Then, the developers can consider what to do. For example, use a different ML
which handles unloved patches, and make it possible to send the proposed patches
to linux-next and linux without Reveiwed-by: or Acked-by: from maintainers,
unless Sashiko finds a new problem introduced by the proposed patches.

Current situation (no response from developers / maintainers) is a deadlock.