public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Frederic Weisbecker <fweisbec@gmail.com>
To: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Li Zefan <lizf@cn.fujitsu.com>,
	Masami Hiramatsu <mhiramat@redhat.com>,
	Jason Baron <jbaron@redhat.com>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	Martin Schwidefsky <schwidefsky@de.ibm.com>,
	Paul Mundt <lethal@linux-sh.org>
Subject: Re: [PATCH 1/2] tracing: Move syscalls metadata handling from arch to core
Date: Sat, 19 Sep 2009 10:12:09 +0200	[thread overview]
Message-ID: <20090919081208.GD5226@nowhere> (raw)
In-Reply-To: <20090919074816.GA4783@osiris.boeblingen.de.ibm.com>

On Sat, Sep 19, 2009 at 09:48:16AM +0200, Heiko Carstens wrote:
> On Sat, Sep 19, 2009 at 07:39:16AM +0200, Frederic Weisbecker wrote:
> > Most of the syscalls metadata processing is done from arch.
> > But these operations are mostly generic accross archs. Especially now
> > that we have a common variable name that expresses the number of
> > syscalls supported by an arch: NR_syscalls, the only remaining bits
> > that need to reside in arch is the syscall nr to addr translation.
> 
> That won't work in its current form, since there is a small difference
> between x86 and s390:
> 
> > diff --git a/arch/s390/kernel/ftrace.c b/arch/s390/kernel/ftrace.c
> > index 57bdcb1..7c5752c 100644
> > --- a/arch/s390/kernel/ftrace.c
> > +++ b/arch/s390/kernel/ftrace.c
> > -static struct syscall_metadata *find_syscall_meta(unsigned long syscall)
> > -{
> > -	struct syscall_metadata *start;
> > -	struct syscall_metadata *stop;
> > -	char str[KSYM_SYMBOL_LEN];
> > -
> > -	start = (struct syscall_metadata *)__start_syscalls_metadata;
> > -	stop = (struct syscall_metadata *)__stop_syscalls_metadata;
> > -	kallsyms_lookup(syscall, NULL, NULL, NULL, str);
> > -
> > -	for ( ; start < stop; start++) {
> > -		if (start->name && !strcmp(start->name + 3, str + 3))
>                                            ^^^^^^^^^^^^^^^^^^^^^^^^



Oh, I thought it was to zap the "sys" prefix comparison.



> > diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
> > index 9dbb527..4adb867 100644
> > --- a/arch/x86/kernel/ftrace.c
> > +++ b/arch/x86/kernel/ftrace.c
> > -static struct syscall_metadata *find_syscall_meta(unsigned long *syscall)
> > -{
> > -	struct syscall_metadata *start;
> > -	struct syscall_metadata *stop;
> > -	char str[KSYM_SYMBOL_LEN];
> > -
> > -
> > -	start = (struct syscall_metadata *)__start_syscalls_metadata;
> > -	stop = (struct syscall_metadata *)__stop_syscalls_metadata;
> > -	kallsyms_lookup((unsigned long) syscall, NULL, NULL, NULL, str);
> > -
> > -	for ( ; start < stop; start++) {
> > -		if (start->name && !strcmp(start->name, str))
>                                            ^^^^^^^^^^^^^^^^
> > -			return start;
> > -	}
> > -	return NULL;
> 
> The reason for the "+ 3 " is that architectures with syscall wrappers have
> alias function names which also show up in kallsysms:
> 
> 000000000001c788 t show_cpuinfo
> 000000000001c9e0 T SyS_s390_personality
> 000000000001c9e0 T sys_s390_personality
> 000000000001ca48 T SyS_s390_newuname
> 000000000001ca48 T sys_s390_newuname
> 000000000001cac8 T SyS_ipc
> 000000000001cac8 T sys_ipc
> 000000000001cd00 T SyS_s390_old_mmap
> 000000000001cd00 T sys_s390_old_mmap
> 000000000001ce68 T SyS_mmap2
> 000000000001ce68 T sys_mmap2
> 000000000001cfc4 t FixPerRegisters
> 
> So kallsyms_lookup(...) would currently always return a string that starts
> with "SyS" instead of "sys". Since the metadata syscall names start with
> "sys" there is no match.
> If you could change the generic version so it also contains a "+ 3" it
> should work for all architectures.
> Might be worth a comment that I didn't add back then :)



Ah ok. So the fix is easy.
Thanks for the tip!


> Hmm... maybe it's even possible to throw out the "SyS" variants out of
> the kallsyms table and only keep the alias names?
> That would shrink the kernel image a bit.


Yeah, unless someone finds strong reasons to keep them.

Thanks!


  reply	other threads:[~2009-09-19  8:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-19  5:39 [GIT PULL] tracing/syscalls: Arch code shrinks, easier arch integration Frederic Weisbecker
2009-09-19  5:39 ` [PATCH 1/2] tracing: Move syscalls metadata handling from arch to core Frederic Weisbecker
2009-09-19  7:16   ` Ingo Molnar
2009-09-19  7:48   ` Heiko Carstens
2009-09-19  8:12     ` Frederic Weisbecker [this message]
2009-09-19  5:39 ` [PATCH 2/2] tracing: Document HAVE_FTRACE_SYSCALLS needs Frederic Weisbecker
2009-09-19  7:17   ` Ingo Molnar
2009-09-19  7:22     ` Frederic Weisbecker
2009-09-19  7:28       ` Ingo Molnar
2009-09-19  7:29         ` Frederic Weisbecker
2009-09-19  9:08 ` [GIT PULL v2] tracing/syscalls: Arch code shrinks, easier arch integration Frederic Weisbecker
2009-10-13 22:25   ` Frederic Weisbecker
2009-10-14  6:18     ` Ingo Molnar
2009-10-14  7:28       ` Heiko Carstens
2009-09-19  9:08 ` [PATCH 1/2 v2] tracing: Move syscalls metadata handling from arch to core Frederic Weisbecker
2009-09-19  9:08 ` [PATCH 2/2 v2] tracing: Document HAVE_SYSCALL_TRACEPOINTS needs Frederic Weisbecker

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=20090919081208.GD5226@nowhere \
    --to=fweisbec@gmail.com \
    --cc=heiko.carstens@de.ibm.com \
    --cc=jbaron@redhat.com \
    --cc=laijs@cn.fujitsu.com \
    --cc=lethal@linux-sh.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizf@cn.fujitsu.com \
    --cc=mhiramat@redhat.com \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=schwidefsky@de.ibm.com \
    /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