linux-kernel - Re: "immediate fixes" for user-reported regressions (was: Re: [GIT PULL] pwm: Two fixes and a maintainer update)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAHk-=wi86AosXs66-yi54+mpQjPu0upxB8ZAfG+LsMyJmcuMSA@mail.gmail.com>
Date: Wed, 28 Jan 2026 09:25:24 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Thorsten Leemhuis <regressions@...mhuis.info>
Cc: Uwe Kleine-König <u.kleine-koenig@...libre.com>, 
	linux-pwm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Michal Wilczynski <m.wilczynski@...sung.com>, Maxime Ripard <mripard@...hat.com>, 
	Richard Genoud <richard.genoud@...tlin.com>
Subject: Re: "immediate fixes" for user-reported regressions (was: Re: [GIT
 PULL] pwm: Two fixes and a maintainer update)

On Wed, 28 Jan 2026 at 08:12, Thorsten Leemhuis
<regressions@...mhuis.info> wrote:
>
> So how can I/we make "immediate fixes" happen more often without
> contributing to maintainer burnout?

This is partly why I mentioned the "revert and rethink" model. A lot
of maintainers already do that for late regressions because they don't
want to have a hurried fix late in the rc, but I think it's just often
a good idea in general unless there's just an obvious fix for an
obvious bug (and often it really is obvious once somebody reports
problems and the commit that caused them has been pinpointed).

Exactly so that maintainers don't get stressed out over having a
pending problem report that people keep pestering them about.

I think people are sometimes a bit too bought into whatever changes
they made, and reverting is seen as "too drastic", but I think it's
often the quick and easy solution for when there isn't some obvious
response to a regression report.

It's also worth noting that "immediate" obviously doesn't mean "right
this *second* when the problem has been reported".

But if it's a regression with a known commit that caused it, I think
the rule of thumb should generally be "within a week", preferably
before the next rc.

> We could obviously start bypassing the regular channels occasionally
> when no "immediate fix" comes forward through them if that's what you
> want.

I do actually do that when something hasn't been fixed and people
point out a known fix (or revert) that has been pending for weeks and
causes problems for people.

Of course, by the time something is at the point where it's been
escalated to me, it usually means that it's really been _way_ too
long. So that's not the good case.

                Linus