All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wu Zhangjin <wuzhangjin@gmail.com>
To: David Daney <david.s.daney@gmail.com>
Cc: Ralf Baechle <ralf@linux-mips.org>,
	linux-mips <linux-mips@linux-mips.org>
Subject: Re: [PATCH 9/9] tracing: MIPS: cleanup of the address space checking
Date: Thu, 13 May 2010 10:19:36 +0800	[thread overview]
Message-ID: <1273717176.26290.42.camel@localhost> (raw)
In-Reply-To: <4BEAE19D.40502@gmail.com>

On Wed, 2010-05-12 at 10:13 -0700, David Daney wrote:
> On 05/12/2010 06:23 AM, Wu Zhangjin wrote:
> > From: Wu Zhangjin<wuzhangjin@gmail.com>
> >
> > This patch adds an inline function in_module() to check which space the
> > instruction pointer in, kernel space or module space.
> >
> > Note: This may not work when the kernel is compiled with -msym32.
> >
> 
> The kernel is always compiled with -msym32, so the patch is a bit pointless.
> 
> 

In reality, with -msym32, it works well on my machine, but seems you and
some other people told me that it may not work when the kernel and
module space are the same with -msym32 and some other options. perhaps I
need to change the comments to just:

Note: This will not work when the kernel and module space are the same.

If the kernel and module space are the same, We just need to modify the
recording of the calling site to _mcount in scripts/recordmcount.pl and
tune the related address handling in
ftrace_make_nop()/ftrace_make_call().

But I have no such situation to test, how can I simply let the module
has the same address space as the kernel. without -mlong-calls? and
should we change arch/mips/kernel/vmlinux.lds.S and
arch/mips/kernel/module.c?

If the module space and kernel space are the same, we may remove the
long call from the module space to kernel space to speedup the function
call.

> >
> > diff --git a/arch/mips/kernel/ftrace.c b/arch/mips/kernel/ftrace.c
> > index 628e90b..37f15b6 100644
> > --- a/arch/mips/kernel/ftrace.c
> > +++ b/arch/mips/kernel/ftrace.c
> > @@ -17,6 +17,17 @@
> >   #include<asm/cacheflush.h>
> >   #include<asm/uasm.h>
> >
> > +/*
> > + * If the Instruction Pointer is in module space (0xc0000000), return true;
> > + * otherwise, it is in kernel space (0x80000000), return false.
> > + *
> > + * FIXME: This may not work when the kernel is compiled with -msym32.
> > + */
> > +static inline int in_module(unsigned long ip)
> > +{
> > +	return ip&  0x40000000;
> > +}
> > +
> 
> How about (untested):
> 
> 
> static inline int in_module(unsigned long ip)
> {
> 	return ip < _text || ip > _etext;
> }
> 

It may work, thanks!

> 
> But why do we even care?  Can't we just probe the function prologue and 
> determine from that what needs to be done?

Yes, it should work via checking the instructions in the memory before
the ip but I think a lighter solution is better.

Thanks & Regards,
	Wu Zhangjin

  reply	other threads:[~2010-05-13  2:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-05-12 13:23 [PATCH v6 0/9] tracing: MIPS: add misc fixups and cleanups Wu Zhangjin
2010-05-12 13:23 ` [PATCH 1/9] tracing: MIPS: mcount.S: merge the same continuous #ifdefs Wu Zhangjin
2010-05-12 13:23 ` [PATCH 2/9] tracing: MIPS: mcount.S: Fixup of the 32bit support with gcc 4.5 Wu Zhangjin
2010-05-12 17:16   ` David Daney
2010-05-13  1:35     ` Wu Zhangjin
2010-05-12 13:23 ` [PATCH 3/9] tracing: MIPS: mcount.S: cleanup the arguments of prepare_ftrace_return Wu Zhangjin
2010-05-12 13:23 ` [PATCH 4/9] tracing: MIPS: mcount.S: cleanup of the comments Wu Zhangjin
2010-05-12 13:23 ` [PATCH 5/9] tracing: MIPS: Fixup of the 32bit support with -mmcount-ra-address Wu Zhangjin
2010-05-12 13:23 ` [PATCH 6/9] tracing: MIPS: cleanup of the instructions Wu Zhangjin
2010-05-12 13:23 ` [PATCH 7/9] tracing: MIPS: Reduce the overhead of dynamic Function Tracer Wu Zhangjin
2010-05-12 13:23 ` [PATCH 8/9] tracing: MIPS: cleanup of function graph tracer Wu Zhangjin
2010-05-12 13:23 ` [PATCH 9/9] tracing: MIPS: cleanup of the address space checking Wu Zhangjin
2010-05-12 17:13   ` David Daney
2010-05-13  2:19     ` Wu Zhangjin [this message]
2010-05-13 16:13     ` Ralf Baechle
2010-05-13 16:17       ` David Daney
  -- strict thread matches above, loose matches on Subject: below --
2010-05-14 11:08 [PATCH v7 0/9] tracing: MIPS: add misc fixups and cleanups Wu Zhangjin
2010-05-14 11:08 ` [PATCH 9/9] tracing: MIPS: cleanup of the address space checking Wu Zhangjin
2010-05-27 11:28   ` Ralf Baechle

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=1273717176.26290.42.camel@localhost \
    --to=wuzhangjin@gmail.com \
    --cc=david.s.daney@gmail.com \
    --cc=linux-mips@linux-mips.org \
    --cc=ralf@linux-mips.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.