lkml.org 
[lkml]   [2016]   [Aug]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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

\
 
 \ /
  Last update: 2016-09-17 09:58    [W:0.116 / U:0.644 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site