[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220502175921.oruktb6dleabvdyx@treble>
Date: Mon, 2 May 2022 10:59:21 -0700
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: x86@...nel.org, linux-kernel@...r.kernel.org,
Masami Hiramatsu <mhiramat@...nel.org>
Subject: Re: [PATCH] objtool: Fix STACK_FRAME_NON_STANDARD reloc type
On Sat, Apr 30, 2022 at 01:44:00PM +0200, Peter Zijlstra wrote:
> > > I also don't see any kprobe/optprobe hooks in unwind.h, so what happens
> > > if we hit an optprobe?
> >
> > Same as for any other generated code, the unwinder will try to fall back
> > to frame pointers, and if that doesn't work, the unwind stops.
> >
> > That commit didn't change anything since it was already not being
> > directly executed anyway, but rather used to generate code on the fly.
> >
> > And before that commit it was being ignored by ORC anyway, thanks to
> > STACK_FRAME_NON_STANDARD. Which can now be removed since this code is
> > now data and objtool will no longer try to understand it.
>
> Right; but I suppose I'm wondering if we should fix this. It seems a
> rather sub-optimal state of affairs.
Masami recently fixed some kprobes ORC issues but I don't know if this
one was fixed.
As to the whether it's worth fixing, I dunno. There are trade offs.
Depends on how common the stack trace is -- I'm guessing not very, since
I've never seen a bug report -- and how important it is to get to full
ORC coverage. If our goal is full coverage, we'd need a way for
generated code to add/remove ORC entries.
--
Josh
Powered by blists - more mailing lists