This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

manual SyS_foo management is unnecessary?


I've had my hands on a powerpc machine the last few days, which is one
of the architectures which uses SYSCALL_WRAPPERS (creating SyS_foo for
system calls instead of sys_foo).  I've also been improving our alias
support, and I discovered that SYSCALL_WRAPPERS have also defined the
traditional aliased name as far back as I can see.  So this works:

  $ stap -l 'kernel.function("sys_open*")'
  kernel.function("SyS_open@fs/open.c:1053")
  kernel.function("SyS_openat@fs/open.c:1067")

Now all over our syscall tapset, we have probes like:

  probe syscall.open = kernel.function("compat_sys_open").call ?,
                       kernel.function("sys32_open").call ?,
                       kernel.function("SyS_open").call !,
                       kernel.function("sys_open").call ?

With alias-resolution in place, that "SyS_open!,sys_open" bit is
unnecessary, but harmless.  There are worse cases though:

  probe syscall.sendfile = kernel.function("SyS_sendfile").call ?,
                           kernel.function("sys_sendfile").call ?,
                           kernel.function("SyS_sendfile64").call ?,
                           kernel.function("sys_sendfile64").call ?

Since this doesn't have !-sufficiency, and we resolve the sys_sendfile
alias too, we end up with duplicate probes.  We'd have to be a bit more
clever with some private tapset names to get around this.

(Note: we do detect duplicate addresses for wildcard matching, but that
doesn't come into play with distinct probe specifications as above.  We
can't really know if the duplication was intended.)


This also comes into play with nd_syscalls, because that tapset can't
use !-sufficiency at all:

  probe nd_syscall.open = kprobe.function("compat_sys_open") ?,
                          kprobe.function("sys32_open") ?,
                          kprobe.function("SyS_open") ?,
                          kprobe.function("sys_open") ?

The kprobe.function is resolved only at runtime, where kprobes uses
kallsyms to map the symbol name to an address.  It turns out, at least
on recent kernels, that kallsyms also resolves aliased names.  So again
SyS_open and sys_open create duplicate probe addresses.


So, I don't think we need to concern ourselves with SyS_foo at all in
the tapset, and in fact I think it's harmful how we have it now.  I have
a large patch to remove all the SyScalls so we can just let aliasing do
its job.  This requires two assumptions:

1. SYSCALL_WRAPPERS have always defined SyS-sys aliases.  I believe
   this is true, so our translator can rely on the alias to get to the
   real function in the syscall tapset.

2. kallsyms has always resolved aliased names.  I'm less sure about
   this, but it appears to be the case.  If so, we can also let the
   nd_syscalls tapset rely on aliases to do the right thing.

If this seems ok, I will commit the SyS removal...

Thanks,
Josh


PS - ppc arguments appear broken in nd_syscall - anyone know why?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]