Messages in this thread | | | From | Andy Lutomirski <> | Date | Tue, 30 Aug 2016 12:53:53 -0700 | Subject | Re: [PATCH 1/2] tracing/syscalls: allow multiple syscall numbers per syscall |
| |
On Tue, Aug 30, 2016 at 12:29 PM, Steven Rostedt <rostedt@goodmis.org> wrote: > On Tue, 30 Aug 2016 11:52:39 -0700 > Andy Lutomirski <luto@amacapital.net> wrote: > > >> Okay, I think I see what's going on. init_ftrace_syscalls() does: >> >> meta = find_syscall_meta(addr); >> >> Unless I'm missing some reason why this is a sensible thing to do, >> this seems overcomplicated and incorrect. There is exactly one caller >> of find_syscall_meta() and that caller knows the syscall number. Why >> doesn't it just look up the metadata by *number* instead of by syscall >> implementation address? There are plenty of architectures for which >> multiple logically different syscalls can share an implementation >> (e.g. pretty much everything that calls in_compat_syscall()). > > The problem is that the meta data is created at the syscalls > themselves. Look at all the macro magic in include/linux/syscalls.h, > and search for __syscall_metadata. The meta data is created via linker > magic, and the find_syscall_meta() is what finds a specific system call > and the meta data associated with it.
Egads! OK, I see why this is a mess.
I guess we should be creating the metadata from the syscall tables instead of from the syscall definitions, but I guess that's currently a nasty per-arch mess.
Could we at least have an array of (arch, nr) instead of just an array of nrs in the metadata?
--Andy
| |