public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Paul Mackerras <paulus@samba.org>,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	Oleg Nesterov <oleg@redhat.com>
Subject: Re: [PATCHv2] perf x86_64: Fix rsp register for system call fast path
Date: Tue, 2 Oct 2012 17:49:26 +0200	[thread overview]
Message-ID: <20121002154914.GC10605@somewhere> (raw)
In-Reply-To: <20121002145815.GH6379@krava.brq.redhat.com>

On Tue, Oct 02, 2012 at 04:58:15PM +0200, Jiri Olsa wrote:
> diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
> index 915b876..11d62ff 100644
> --- a/arch/x86/kernel/cpu/perf_event.c
> +++ b/arch/x86/kernel/cpu/perf_event.c
> @@ -34,6 +34,7 @@
>  #include <asm/timer.h>
>  #include <asm/desc.h>
>  #include <asm/ldt.h>
> +#include <asm/syscall.h>
>  
>  #include "perf_event.h"
>  
> @@ -1699,6 +1700,52 @@ void arch_perf_update_userpage(struct perf_event_mmap_page *userpg, u64 now)
>  	userpg->time_offset = this_cpu_read(cyc2ns_offset) - now;
>  }
>  
> +#ifdef CONFIG_X86_64
> +__weak int arch_sample_regs_user(struct pt_regs *oregs, struct pt_regs *regs)
> +{
> +	int kernel = !user_mode(regs);
> +
> +	if (kernel) {
> +		if (current->mm)
> +			regs = task_pt_regs(current);
> +		else
> +			regs = NULL;
> +	}

Shouldn't the above stay in generic code?

> +
> +	if (regs) {
> +		memcpy(oregs, regs, sizeof(*regs));
> +
> +		/*
> +		 * If the perf event was triggered within the kernel code
> +		 * path, then it was either syscall or interrupt. While
> +		 * interrupt stores almost all user registers, the syscall
> +		 * fast path does not. At this point we can at least set
> +		 * rsp register right, which is crucial for dwarf unwind.
> +		 *
> +		 * The syscall_get_nr function returns -1 (orig_ax) for
> +		 * interrupt, and positive value for syscall.
> +		 *
> +		 * We have two race windows in here:
> +		 *
> +		 * 1) Few instructions from syscall entry until old_rsp is
> +		 *    set.
> +		 *
> +		 * 2) In syscall/interrupt path from entry until the orig_ax
> +		 *    is set.
> +		 *
> +		 * Above described race windows are fractional opposed to
> +		 * the syscall fast path, so we get much better results
> +		 * fixing rsp this way.

That said, a race is there already: if the syscall is interrupted before
SAVE_ARGS and co.

I'm trying to scratch my head to find a solution to detect the race and
bail out instead of recording erroneous values but I can't find one.

Anyway this is still better than what we have now.

Another solution could be to force syscall slow path and have some variable
set there that tells us we are in a syscall and every regs have been saved.

But we probably don't want to force syscall slow path...

  reply	other threads:[~2012-10-02 15:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-01 17:31 [PATCH] perf x86_64: Fix rsp register for system call fast path Jiri Olsa
2012-10-02 10:44 ` Peter Zijlstra
2012-10-02 14:58   ` [PATCHv2] " Jiri Olsa
2012-10-02 15:49     ` Frederic Weisbecker [this message]
2012-10-02 16:06       ` Jiri Olsa
2012-10-02 16:16         ` Frederic Weisbecker
2012-10-03 12:29           ` [PATCHv3] " Jiri Olsa
2012-10-03 12:35             ` Frederic Weisbecker
2012-10-03 13:13               ` [PATCHv4] " Jiri Olsa
2012-10-03 13:22                 ` Peter Zijlstra
2012-10-03 13:30                   ` Jiri Olsa
2012-10-04 10:38                     ` [PATH 0/2] perf: x86_64 rsp related changes Jiri Olsa
2012-10-04 10:38                       ` [PATCH 1/2] perf x86_64: Fix rsp register for system call fast path Jiri Olsa
2012-10-04 10:38                       ` [PATCH 2/2] perf: Simplify the sample's user regs/stack retrieval Jiri Olsa

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=20121002154914.GC10605@somewhere \
    --to=fweisbec@gmail.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@redhat.com \
    --cc=paulus@samba.org \
    /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