All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	x86@kernel.org, Dominik Brodowski <linux@dominikbrodowski.net>
Subject: Re: [PATCH v2] tracing/x86: Update syscall trace events to handle new x86 syscall func names
Date: Tue, 17 Apr 2018 14:29:40 -0300	[thread overview]
Message-ID: <20180417172940.GA3625@kernel.org> (raw)
In-Reply-To: <20180417130702.01575029@gandalf.local.home>

Em Tue, Apr 17, 2018 at 01:07:02PM -0400, Steven Rostedt escreveu:
> From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
> 
> Arnaldo noticed that the latest kernel is missing the syscall event system
> directory in x86. I bisected it down to d5a00528b58c ("syscalls/core,
> syscalls/x86: Rename struct pt_regs-based sys_*() to __x64_sys_*()").
> 
> The system call trace events are special, as there is only one trace event
> for all system calls (the raw_syscalls). But a macro that wraps the system
> calls creates meta data for them that copies the name to find the system
> call that maps to the system call table (the number). At boot up, it does a
> kallsyms lookup for this mapping. If it does not find a function, then that
> system call is ignored.
> 
> Because the x86 system calls had "__x64_" appended to the "sys" for the
> names, they do not match the default compare algorithm. As this was a
> problem for power pc, the algorithm can be overwritten by the architecture.
> The solution is to have x86 have its own algorithm to do the compare and
> this brings back the system call trace events.
> 
> Reported-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> Fixes: d5a00528b58c ("syscalls/core, syscalls/x86: Rename struct pt_regs-based sys_*() to __x64_sys_*()")
> Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>

Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>

Again on x86_64, the number of files in
/sys/kernel/debug/tracing/events/syscalls/ is the same, all my perf
related tests pass.

Now to the next seemingly kernel related test failure, unrelated to
this:

 4: Read samples using the mmap interface                 : FAILED!

- Arnaldo

  parent reply	other threads:[~2018-04-17 17:29 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-17 17:07 [PATCH v2] tracing/x86: Update syscall trace events to handle new x86 syscall func names Steven Rostedt
2018-04-17 17:22 ` Dominik Brodowski
2018-04-17 18:04   ` Arnaldo Carvalho de Melo
2018-04-17 18:13     ` Arnaldo Carvalho de Melo
2018-04-17 18:16       ` Steven Rostedt
2018-04-17 21:41       ` Steven Rostedt
2018-04-18 12:53         ` Arnaldo Carvalho de Melo
2018-04-18 14:36           ` Steven Rostedt
2018-04-18 15:02             ` Arnaldo Carvalho de Melo
2018-04-18 15:17               ` Arnaldo Carvalho de Melo
2018-04-18 15:20                 ` Steven Rostedt
2018-04-18 15:25                   ` Arnaldo Carvalho de Melo
2018-04-18 15:30                     ` Steven Rostedt
2018-04-18 15:45   ` Steven Rostedt
2018-04-17 17:29 ` Arnaldo Carvalho de Melo [this message]
2018-04-17 17:56   ` Arnaldo Carvalho de Melo

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=20180417172940.GA3625@kernel.org \
    --to=acme@kernel.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.net \
    --cc=mingo@kernel.org \
    --cc=rostedt@goodmis.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.