All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Kairui Song <kasong@redhat.com>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@redhat.com>, Namhyung Kim <namhyung@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Borislav Petkov <bp@alien8.de>, Dave Young <dyoung@redhat.com>
Subject: Re: [RFC PATCH v2] perf/x86: make perf callchain work without CONFIG_FRAME_POINTER
Date: Mon, 15 Apr 2019 11:58:59 -0500	[thread overview]
Message-ID: <20190415165859.ul7i2w3lai3umgik@treble> (raw)
In-Reply-To: <20190415153622.GG12232@hirez.programming.kicks-ass.net>

On Mon, Apr 15, 2019 at 05:36:22PM +0200, Peter Zijlstra wrote:
> 
> I'll mostly defer to Josh on unwinding, but a few comments below.
> 
> On Tue, Apr 09, 2019 at 12:59:42AM +0800, Kairui Song wrote:
> > diff --git a/arch/x86/events/core.c b/arch/x86/events/core.c
> > index e2b1447192a8..6075a4f94376 100644
> > --- a/arch/x86/events/core.c
> > +++ b/arch/x86/events/core.c
> > @@ -2355,6 +2355,12 @@ void arch_perf_update_userpage(struct perf_event *event,
> >  	cyc2ns_read_end();
> >  }
> >  
> > +static inline int
> > +valid_perf_registers(struct pt_regs *regs)
> > +{
> > +	return (regs->ip && regs->bp && regs->sp);
> > +}
> 
> I'm unconvinced by this, with both guess and orc having !bp is perfectly
> valid.
> 
> >  void
> >  perf_callchain_kernel(struct perf_callchain_entry_ctx *entry, struct pt_regs *regs)
> >  {
> > @@ -2366,11 +2372,17 @@ perf_callchain_kernel(struct perf_callchain_entry_ctx *entry, struct pt_regs *re
> >  		return;
> >  	}
> >  
> > -	if (perf_callchain_store(entry, regs->ip))
> > +	if (valid_perf_registers(regs)) {
> > +		if (perf_callchain_store(entry, regs->ip))
> > +			return;
> > +		unwind_start(&state, current, regs, NULL);
> > +	} else if (regs->sp) {
> > +		unwind_start(&state, current, NULL, (unsigned long *)regs->sp);
> > +	} else {
> >  		return;
> > +	}
> 
> AFAICT if we, by pure accident, end up with !bp for ORC, then we
> initialize the unwind wrong.
> 
> Note that @regs is mostly trivially correct, except for that tracepoint
> case. So I don't think we should magic here.

Ah, I didn't quite understand this code before, and I still don't
really, but I guess the issue is that @regs can be either real or fake.

In the real @regs case, we just want to always unwind starting from
regs->sp.

But in the fake @regs case, we should instead unwind from the current
frame, skipping all frames until we hit the fake regs->sp.  Because
starting from fake/incomplete regs is most likely going to cause
problems with ORC (or DWARF for other arches).

The idea of a fake regs is fragile and confusing.  Is it possible to
just pass in the "skip" stack pointer directly instead?  That should
work for both FP and non-FP.  And I _think_ there's no need to ever
capture regs->bp anyway -- the stack pointer should be sufficient.

In other words, either regs should be "real", and skip_sp is NULL; or
regs should be NULL and skip_sp should have a value.

-- 
Josh

  reply	other threads:[~2019-04-15 16:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-08 16:59 [RFC PATCH v2] perf/x86: make perf callchain work without CONFIG_FRAME_POINTER Kairui Song
2019-04-15 12:38 ` Jiri Olsa
2019-04-15 15:36 ` Peter Zijlstra
2019-04-15 16:58   ` Josh Poimboeuf [this message]
2019-04-16 11:30     ` Kairui Song
2019-04-16 16:16       ` Alexei Starovoitov
2019-04-16 17:39       ` Kairui Song
2019-04-16 17:45         ` Peter Zijlstra
2019-04-17 14:41           ` Kairui Song
2019-04-16 20:15         ` Josh Poimboeuf
2019-04-17  7:07           ` Peter Zijlstra
2019-04-18  2:15             ` Josh Poimboeuf
2019-04-17 14:44           ` Kairui Song
2019-04-18  7:54             ` Peter Zijlstra

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=20190415165859.ul7i2w3lai3umgik@treble \
    --to=jpoimboe@redhat.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=bp@alien8.de \
    --cc=dyoung@redhat.com \
    --cc=jolsa@redhat.com \
    --cc=kasong@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    /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.