linux-kernel - Re: [GIT pull] sched/core for v5.16-rc1

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-=whEbr+0ZSRMkQ1wqLCeBEiK7o2-Hm=55aTBpdeVxnFbVQ@mail.gmail.com>
Date:   Mon, 1 Nov 2021 14:01:13 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: Re: [GIT pull] sched/core for v5.16-rc1

On Sun, Oct 31, 2021 at 6:16 PM Thomas Gleixner <tglx@...utronix.de> wrote:
>
>  - Make wchan() more robust and work with all kind of unwinders by
>    enforcing that the task stays blocked while unwinding is in progress.

Ugh. This not-very-important data is protected by a rather core lock.

Is this yet another example of "unwinding is so fragile that it can
screw up unless we take a lock that is seriously overkill for a not
very important operation"?

Unwinders that need locks because they can do bad things if they are
working on unstable data are EVIL and WRONG.

I guess I don't care too much about the pi_lock, and the actual
unwinding is hopefully done on tasks that don't care about it, but
this smells suspicious to me.

Why is that "stable wchan" so magically important?

               Linus