From: "Andy Lutomirski" <luto@kernel.org>
To: "Qi Zheng" <zhengqi.arch@bytedance.com>,
"Josh Poimboeuf" <jpoimboe@redhat.com>,
"Vito Caputo" <vcaputo@pengaru.com>
Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
"the arch/x86 maintainers" <x86@kernel.org>,
"Peter Zijlstra (Intel)" <peterz@infradead.org>,
"Jann Horn" <jannh@google.com>,
"Kees Cook" <keescook@chromium.org>
Subject: Re: CONFIG_ORC_UNWINDER=y breaks get_wchan()?
Date: Mon, 04 Oct 2021 17:51:14 -0700 [thread overview]
Message-ID: <b255e8ec-911e-4ddd-8e0f-1ff0f7938469@www.fastmail.com> (raw)
In-Reply-To: <930f0c5e-0fd4-aae7-334f-ec9cc42998a4@bytedance.com>
On Tue, Sep 21, 2021, at 8:30 PM, Qi Zheng wrote:
> On 9/22/21 8:15 AM, Josh Poimboeuf wrote:
>> On Tue, Sep 21, 2021 at 12:32:49PM -0700, Vito Caputo wrote:
>>> Is this an oversight of the ORC_UNWINDER implementation? It's
>>> arguably a regression to completely break wchans for tools like `ps -o
>>> wchan` and `top`, or my window manager and its separate monitoring
>>> utility. Presumably there are other tools out there sampling wchans
>>> for monitoring as well, there's also an internal use of get_chan() in
>>> kernel/sched/fair.c for sleep profiling.
>>>
>>> I've occasionally seen when monitoring at a high sample rate (60hz) on
>>> something churny like a parallel kernel or systemd build, there's a
>>> spurious non-zero sample coming out of /proc/[pid]/wchan containing a
>>> hexadecimal address like 0xffffa9ebc181bcf8. This all smells broken,
>>> is get_wchan() occasionally spitting out random junk here kallsyms
>>> can't resolve, because get_chan() is completely ignorant of
>>> ORC_UNWINDER's effects?
>>
>> Hi Vito,
>>
>> Thanks for reporting this. Does this patch fix your issue?
>>
>> https://lkml.kernel.org/r/20210831083625.59554-1-zhengqi.arch@bytedance.com
>>
>> Though, considering wchan has been silently broken for four years, I do
>> wonder what the impact would be if we were to just continue to show "0"
>> (and change frame pointers to do the same).
>
> Agree, Or remove get_wchan() directly.
I agree. wchan is a hack that may or may not do anything useful. We certainly should not be reporting things derived from the stack trace to unprivileged tasks. And it's probably just as racy as /proc/.../stack.
next prev parent reply other threads:[~2021-10-05 0:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-21 19:32 CONFIG_ORC_UNWINDER=y breaks get_wchan()? Vito Caputo
2021-09-22 0:15 ` Josh Poimboeuf
2021-09-22 3:04 ` Kees Cook
2021-09-23 23:59 ` Jann Horn
2021-09-25 19:07 ` David Laight
2021-09-22 3:30 ` Qi Zheng
2021-10-05 0:51 ` Andy Lutomirski [this message]
2021-09-24 5:46 ` Vito Caputo
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=b255e8ec-911e-4ddd-8e0f-1ff0f7938469@www.fastmail.com \
--to=luto@kernel.org \
--cc=jannh@google.com \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=vcaputo@pengaru.com \
--cc=x86@kernel.org \
--cc=zhengqi.arch@bytedance.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.