Re: manual SyS_foo management is unnecessary?

[David Smith <dsmith at redhat dot com>]

On 06/14/2010 02:52 PM, Josh Stone wrote:
> 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")

Interesting.  I hadn't realized pr10327 applied to kernel space as well
as user space (since all the examples in pr10327 only applied to user
space).

> 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.)

Why does the above example need private tapset names?  Couldn't it just be:

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

On s390x anyway, those 2 functions don't appear to be aliases of each other:

# stap -l 'kernel.function("sys_sendfile")'
kernel.function("SyS_sendfile@fs/read_write.c:880")
# stap -l 'kernel.function("sys_sendfile64")'
kernel.function("SyS_sendfile64@fs/read_write.c:899")

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

Hmm, what exactly do you mean by broken?

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)