All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: T??r??k Edwin <edwintorok@gmail.com>, "H. Peter Anvin" <hpa@zytor.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Paul Mackerras <paulus@samba.org>,
	x86@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] perf: x86: fix callgraphs of 32-bit processes on 64-bit kernels V2.
Date: Tue, 16 Mar 2010 18:05:49 +0100	[thread overview]
Message-ID: <20100316170549.GC17537@elte.hu> (raw)
In-Reply-To: <1268751734-9167-1-git-send-email-edwintorok@gmail.com>


* T??r??k Edwin <edwintorok@gmail.com> wrote:

> When profiling a 32-bit process on a 64-bit kernel, callgraph tracing
> stopped after the first function, because it has seen a garbage memory address
> (tried to interpret the frame pointer, and return address as a 64-bit pointer).
> 
> Fix this by using a struct stack_frame with 32-bit pointers when the TIF_IA32 flag is set.
> 
> Note that TIF_IA32 flag must be used, and not is_compat_task(), because the
> latter is only set when the 32-bit process is executing a syscall,
> which may not always be the case (when tracing page fault events for example).
> 
> Signed-off-by: T??r??k Edwin <edwintorok@gmail.com>
> ---
>  arch/x86/kernel/cpu/perf_event.c |   33 +++++++++++++++++++++++++++++++++
>  1 files changed, 33 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c
> index 8c1c070..b85ea9f 100644
> --- a/arch/x86/kernel/cpu/perf_event.c
> +++ b/arch/x86/kernel/cpu/perf_event.c
> @@ -2401,6 +2401,20 @@ static int copy_stack_frame(const void __user *fp, struct stack_frame *frame)
>  	return bytes == sizeof(*frame);
>  }
>  
> +struct stack_frame_ia32 {
> +    u32 next_frame;
> +    u32 return_address;
> +};

Please put such new data type definitions not into the middle of a .c file but 
next to where struct stack_frame is defined.

> +
> +static int copy_stack_frame_ia32(u32 fp, struct stack_frame_ia32 *frame)
> +{
> +	unsigned long bytes;
> +
> +	bytes = copy_from_user_nmi(frame, (const void __user*)(unsigned long)fp, sizeof(*frame));
> +
> +	return bytes == sizeof(*frame);
> +}
>

Single-use - should be inline i guess.

> +
>  static void
>  perf_callchain_user(struct pt_regs *regs, struct perf_callchain_entry *entry)
>  {
> @@ -2414,6 +2428,25 @@ perf_callchain_user(struct pt_regs *regs, struct perf_callchain_entry *entry)
>  
>  	callchain_store(entry, PERF_CONTEXT_USER);
>  	callchain_store(entry, regs->ip);
> +	if (test_thread_flag(TIF_IA32)) {
> +	    /* 32-bit process in 64-bit kernel. */
> +	    u32 fp = regs->bp;
> +	    struct stack_frame_ia32 frame;
> +	    while (entry->nr < PERF_MAX_STACK_DEPTH) {

Please put newlines after local variable definition so that they are clearly 
delimited.

Also, the tabulation is weird - please run it through scripts/checkpatch.pl.

> +		frame.next_frame     = 0;
> +		frame.return_address = 0;
> +
> +		if (!copy_stack_frame_ia32(fp, &frame))
> +			break;
> +
> +		if (fp < (u32)regs->sp)
> +			break;
> +
> +		callchain_store(entry, frame.return_address);
> +		fp = frame.next_frame;
> +	    }
> +	    return;

This whole new block should probably be in a helper inline?

Also, it should probably be #ifdef CONFIG_COMPAT or so.

Thanks,

	Ingo

  reply	other threads:[~2010-03-16 17:06 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-03-15 15:34 fix callgraphs of 32-bit processes on 64-bit kernels Török Edwin
2010-03-15 15:34 ` [PATCH] perf: x86: " Török Edwin
2010-03-16 14:49   ` Frederic Weisbecker
2010-03-16 15:02     ` [PATCH] perf: x86: fix callgraphs of 32-bit processes on 64-bit kernels V2 Török Edwin
2010-03-16 17:05       ` Ingo Molnar [this message]
2010-03-17  8:48         ` Török Edwin
2010-03-17  8:49           ` [PATCH] perf: x86: fix callgraphs of 32-bit processes on 64-bit kernels V3 Török Edwin
2010-03-17  9:54             ` Ingo Molnar
2010-03-17 10:07             ` [PATCH] perf: x86: fix callgraphs of 32-bit processes on 64-bit kernels V4 Török Edwin
2010-03-30 23:18               ` Frederic Weisbecker
2010-03-17  9:59           ` [PATCH] perf: x86: fix callgraphs of 32-bit processes on 64-bit kernels V2 Ingo Molnar
2010-03-16 15:04     ` [PATCH] perf: x86: fix callgraphs of 32-bit processes on 64-bit kernels Török Edwin
2010-03-15 16:23 ` Török Edwin
2010-03-16  8:18   ` Török Edwin
2010-03-16  8:47     ` Ingo Molnar
2010-03-16 10:17       ` Török Edwin
2010-03-16 10:23         ` Ingo Molnar
2010-03-16  9:57     ` [PATCH] perf: install into /usr/local by default Török Edwin
2010-03-16 10:10       ` Ingo Molnar
2010-03-16 10:20         ` Avi Kivity
2010-03-16 10:25           ` Ingo Molnar
2010-03-16 10:24         ` Török Edwin

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=20100316170549.GC17537@elte.hu \
    --to=mingo@elte.hu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=edwintorok@gmail.com \
    --cc=fweisbec@gmail.com \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=paulus@samba.org \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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 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.