From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Daniel Xu <dxu@dxuuu.xyz>
Cc: Masami Hiramatsu <mhiramat@kernel.org>,
rostedt@goodmis.org, kuba@kernel.org, ast@kernel.org,
tglx@linutronix.de, mingo@redhat.com, x86@kernel.org,
linux-kernel@vger.kernel.org, bpf@vger.kernel.org,
kernel-team@fb.com, yhs@fb.com
Subject: Re: [PATCH] x86: kprobes: orc: Fix ORC walks in kretprobes
Date: Fri, 5 Mar 2021 13:32:44 -0600 [thread overview]
Message-ID: <20210305193244.odtphdj5wm5cslf7@treble> (raw)
In-Reply-To: <20210305192515.6utyhm5kks4zexwn@maharaja.localdomain>
On Fri, Mar 05, 2021 at 11:25:15AM -0800, Daniel Xu wrote:
> > BTW, is this a regression? or CONFIG_UNWINDER_ORC has this issue before?
> > It seems that the above commit just changed the default unwinder. This means
> > OCR stack unwinder has this bug before that commit.
>
> I see your point -- I suppose it depends on point of view. Viewed from
> userspace, a change in kernel defaults means that one kernel worked and
> the next one didn't -- all without the user doing anything. Consider it
> from the POV of a typical linux user who just takes whatever the distro
> gives them and doesn't compile their own kernels.
>
> From the kernel point of view, you're also right. ORC didn't regress, it
> was always broken for this particular use case. But as a primarily
> userspace developer, I would consider this a kernel regression.
Either way, if the bug has always existed in the ORC unwinder, the Fixes
tag needs to reference the original ORC commit:
Fixes: ee9f8fce9964 ("x86/unwind: Add the ORC unwinder")
That makes it possible for stable kernels to identify the source of the
bug and corresponding fix. Many people used the ORC unwinder before it
became the default.
--
Josh
next prev parent reply other threads:[~2021-03-05 19:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-05 0:07 [PATCH] x86: kprobes: orc: Fix ORC walks in kretprobes Daniel Xu
2021-03-05 9:28 ` Masami Hiramatsu
2021-03-05 10:58 ` Masami Hiramatsu
2021-03-05 19:25 ` Daniel Xu
2021-03-05 19:32 ` Josh Poimboeuf [this message]
2021-03-05 20:45 ` Daniel Xu
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=20210305193244.odtphdj5wm5cslf7@treble \
--to=jpoimboe@redhat.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=dxu@dxuuu.xyz \
--cc=kernel-team@fb.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yhs@fb.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox