[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210305193244.odtphdj5wm5cslf7@treble>
Date: Fri, 5 Mar 2021 13:32:44 -0600
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Daniel Xu <dxu@...uu.xyz>
Cc: Masami Hiramatsu <mhiramat@...nel.org>, rostedt@...dmis.org,
kuba@...nel.org, ast@...nel.org, tglx@...utronix.de,
mingo@...hat.com, x86@...nel.org, linux-kernel@...r.kernel.org,
bpf@...r.kernel.org, kernel-team@...com, yhs@...com
Subject: Re: [PATCH] x86: kprobes: orc: Fix ORC walks in kretprobes
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
Powered by blists - more mailing lists