linux-kernel - 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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHk-=wga8Qu0-OSE9VZbviq9GuqwhPhLUXeAt-S7_9+fMCLkKg@mail.gmail.com>
Date: Tue, 20 Jan 2026 10:11:27 -0800
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Uwe Kleine-König <u.kleine-koenig@...libre.com>
Cc: linux-pwm@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Michal Wilczynski <m.wilczynski@...sung.com>, Richard Genoud <richard.genoud@...tlin.com>
Subject: Re: [GIT PULL] pwm: Two fixes and a maintainer update

On Tue, 20 Jan 2026 at 01:32, Uwe Kleine-König
<u.kleine-koenig@...libre.com> wrote:
>
>    You might argue that this is an ABI change [..]

Pretty much any change can be an ABI change - even totally new
interfaces change behavior in that something that didn't use to do
anything now does something.

And we've actually very much have had things like that happen too,
when broken user space did something odd, and adding a completely new
file in /proc (or something like that) just broke broken user space.

And any bugfix that changes visible behavior is also an "ABI change",
and so there is no practical meaning to the whole otion.

So I absolutely detest the whole notion of "ABI changes". It's a
meaningless concept, and I hate it with a passion, because it then
results in the "opposite" situation where some projects seem to think
that ABI changes are perfectly fine as long as they go along with
version number changes.

The Linux rule for regressions is basically based on the philosophical
question of "If a tree falls in the forest, and nobody is around to
hear it, does it make a sound?".

So the only thing that matters is if something breaks user-*conscious* behavior.

And when that happens, the distinction between "bug fix" and "new
feature" and "ABI change" matters not one whit, and the change needs
to be done differently.

Anyway, I agree that the whole "return proper -EFAULT on user copy
failures" is clearly the right thing to do, and I do not disagree with
the patch at all.

I just wanted to point out that the argument about whether it's an ABI
change or not is irrelevant. If it turns out that some program - not a
test script, but something with relevance to conscious user
expectations - depended on the old broken behavior, then it needs to
be done some other way.

So whether somebody "argues" that the change is an ABI change or not
is simply not relevant to anything.

Obviously some changes are more likely to be user-visible than others,
so people should take that into account in how careful you need to be
about a patch.

This one looks entirely benign, but I wanted to point out that if it
breaks some program - however unlikely that is - it just needs to be
reverted, and it doesn't matter what the change is called.

                     Linus