linux-kernel - Re: [GIT PULL] orphaned patches for 6.11

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-=wjYB_aeCxtBW2+-GqcF2PxwJ5061BFrAMp3mJgBy3GGvQ@mail.gmail.com>
Date: Wed, 24 Jul 2024 22:11:43 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] orphaned patches for 6.11

On Wed, 24 Jul 2024 at 21:24, Tetsuo Handa
<penguin-kernel@...ove.sakura.ne.jp> wrote:
>
> If guard() is already backported to older kernels, that would work for
> the kernel/ksysfs.c part. But I prefer killable version,for a large
> memory allocation which may cause current thread waiting on this lock
> might be chosen as an OOM victim is performed from profile_init().

.. and this is why I'm not taking these patches from you.

WHY WOULD ANYBODY EVER CARE ABOUT A KILLABLE VERSION?

It's literally *nothing* but stupid worthless extra complexity.

There are zero real loads where anybody calls this code in parallel.
Nada. Zilch. There's simply no valid use case. The whole thing is
literally designed to ever be called once.

The *ONLY* valid use case is that this write is called *once* to set
up the profiel buffer (ie will return -EEXIST after it's been set up).
And even that "called once" is a rare thing that doesn't happen in any
normal situation.

And when it is called once, that mutex WILL NEVER BLOCK.

In other words, the only reason the serialization exists is for crazy
syzbot uses.

Really.

And that situation is not worth one single *byte* of complexity, or
one single line of extra source code to worry about.

That situation wants the absolutely minimal possible "this is the
simplest solution so that we can forget about this insane case that
doesn't match any real use-case".

So your "I prefer killable version" is literally a completely unreal
situation. Your argument of "may cause current thread waiting on this
lock" is nonsensical.

Nobody we care about ever waits on that lock, because NOBODY EVER DOES THIS.

Except for a crazy syzbot "do random things in a loop", which is not a
real load.

So no. This is not happening, and you just showed exactly why nobody
wants to take your patch set. Because you make things more complicated
than they need to be for no reason.

Stop it. You need to realize that "syzbot complains" is not a real
load. It may find real bugs, but they are often of exactly the "this
never happens in real life" kind.

That means that the fixes need to be simple and obvious, and not
pointlessly have extra complication for no good reason.

And yes, apparently we should just also move the 'prof_buffer' test
earlier, and do it in profile_tick() too, so that we don't need to
even worry about the cpumask_available thing.

In other words, start looking for the _trivial_ fixes to trivial bugs,
instead of looking for more complicated ways to do them.

               Linus