On Tue, Aug 30, 2016 at 12:29 PM, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > On Tue, 30 Aug 2016 11:52:39 -0700 > Andy Lutomirski <luto@xxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html