From: Linus Torvalds <torvalds@linux-foundation.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"the arch/x86 maintainers" <x86@kernel.org>
Subject: Re: [GIT pull] sched/core for v5.16-rc1
Date: Mon, 1 Nov 2021 14:01:13 -0700 [thread overview]
Message-ID: <CAHk-=whEbr+0ZSRMkQ1wqLCeBEiK7o2-Hm=55aTBpdeVxnFbVQ@mail.gmail.com> (raw)
In-Reply-To: <163572864855.3357115.17938524897008353101.tglx@xen13>
On Sun, Oct 31, 2021 at 6:16 PM Thomas Gleixner <tglx@linutronix.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
next prev parent reply other threads:[~2021-11-01 21:01 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-01 1:15 [GIT pull] irq/core for v5.16-rc1 Thomas Gleixner
2021-11-01 1:15 ` [GIT pull] locking/core " Thomas Gleixner
2021-11-01 21:20 ` pr-tracker-bot
2021-11-01 1:16 ` [GIT pull] objtool/core " Thomas Gleixner
2021-11-01 20:44 ` Linus Torvalds
2021-11-02 8:00 ` Peter Zijlstra
2021-11-02 8:06 ` Borislav Petkov
2021-11-02 9:05 ` Stackleak vs noinstr (Was: [GIT pull] objtool/core for v5.16-rc1) Peter Zijlstra
2021-11-02 10:03 ` Peter Zijlstra
2021-11-02 17:50 ` Linus Torvalds
2021-11-02 21:18 ` Borislav Petkov
2021-11-03 7:18 ` Alexander Popov
2021-11-03 8:19 ` Peter Zijlstra
2022-02-01 23:59 ` Kees Cook
2021-11-01 21:20 ` [GIT pull] objtool/core for v5.16-rc1 pr-tracker-bot
2021-11-01 1:16 ` [GIT pull] perf/core " Thomas Gleixner
2021-11-01 21:20 ` pr-tracker-bot
2021-11-01 1:16 ` [GIT pull] sched/core " Thomas Gleixner
2021-11-01 21:01 ` Linus Torvalds [this message]
2021-11-01 21:27 ` Linus Torvalds
2021-11-02 8:41 ` Peter Zijlstra
2021-11-03 13:52 ` Mark Rutland
2021-11-03 16:23 ` Linus Torvalds
2021-11-02 8:54 ` Peter Zijlstra
2021-11-01 21:20 ` pr-tracker-bot
2021-11-01 1:16 ` [GIT pull] timers/core " Thomas Gleixner
2021-11-01 21:20 ` pr-tracker-bot
2021-11-01 1:16 ` [GIT pull] x86/apic " Thomas Gleixner
2021-11-01 21:20 ` pr-tracker-bot
2021-11-01 1:52 ` [GIT pull RESEND] x86/fpu " Thomas Gleixner
2021-11-01 21:20 ` pr-tracker-bot
2021-11-01 21:19 ` [GIT pull] irq/core " pr-tracker-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHk-=whEbr+0ZSRMkQ1wqLCeBEiK7o2-Hm=55aTBpdeVxnFbVQ@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).