Re: patches for turning tapsets wrt kernel configuration available

[David Smith <dsmith at redhat dot com>]

We'd be fine with taking patches like that - except using
CONFIG_POSIX_MQUEUE is probably the wrong way to go. Instead, make
that probe optional. From looking at sysc_mq_open.stp, I see that:

====
probe syscall.mq_open = dw_syscall.mq_open !, nd_syscall.mq_open ? {}
probe dw_syscall.mq_open = __syscall.mq_open,
                        kernel.function("compat_sys_mq_open").call ?
probe __syscall.mq_open = kernel.function("sys_mq_open").call
probe nd_syscall.mq_open = __nd_syscall.mq_open,
                           __nd_syscall.compat_mq_open ?
probe __nd_syscall.mq_open = kprobe.function("sys_mq_open")
====

To tell you the truth, I thought optional-ness was more 'sticky' than
it appears to be. But, anyway the fix should be adding '?' to the
first items in the dw_syscall.mq_open and nd_syscall.mq_open aliases.

On Thu, Aug 2, 2018 at 1:08 PM Victor Kamensky <kamensky@cisco.com> wrote:
>
> Hi Guys,
>
> Question, do you guys open to accepting patches that would turn available
> tapset wrt available kernel configuration.
>
> Here is an example of a problem that I've run into on some of our
> machines. Probe 'probe nd_syscall.*' failed as follows:
>
> semantic error: while resolving probe point: identifier 'kprobe' at
> /nobackup/kamensky/20180731/binos/linkfarm/sysroot-x86_64_cge7/usr/share/systemtap/tapset/linux/sysc_mq_open.stp:80:30
>          source: probe __nd_syscall.mq_open =
> kprobe.function("sys_mq_open")
>
> it turns out my kernel does not enable CONFIG_POSIX_MQUEUE so sys_mq_open
> function does not exist in kernel. Fix is obvious: to add proper
> '%( CONFIG_POSIX_MQUEUE == "[ym]" %?' in tapset/linux/sysc_mq_open.stp.
> But I wonder whether you guys would accept changes like this. Just wanted
> to check before I spend time on making clean patch. I suspect there are
> more issues like this, which may not be visible on regular distros like
> RedHat and Fedora where system running big fully configured kernel.
>
> Thanks,
> Victor
>


-- 
David Smith
Associate Manager
Red Hat