[DTrace-devel] syscall trampoline and handling args

[Eugene Loh]

I think there is a problem with the syscall trampoline's handling of 
args.  I intend to prepare a patch, but will describe here where I'm 
going in case there is feedback I should consider.

Currently, the syscall trampoline copies some arguments, the number of 
which is set by some dtp_argc, which corresponds to some "representative 
probe."  The problem is that this number of arguments is not necessarily 
the same for every probe that matches the user's probe description.  
E.g., consider "dtrace -n syscall:::entry".  If one examines the 
/sys/kernel/debug/tracing/events/syscalls/sys_enter_*/format files, as 
tp_event_info() does, then one finds a varying number of args, from 0 to 
6.  The number that we copy is set by the "representative probe" -- in 
essence, a "random" value.  This works for some number of other probes.  
For probes that have more arguments, however, the additional args will 
not be copied.  For probes that have fewer arguments, the BPF program 
will not even attach to the probe; the PERF_EVENT_IOC_SET_BPF ioctl in 
dt_bpf_attach() will error.

I'm inclined to:

*)  Change the trampoline code from something like:
          for (i = 0; i < argc; i++) dctx.argv[i] = scd->arg[i];
to something like:
         if (argc > 0) dctx.argv[0] = scd->arg[0];
         if (argc > 1) dctx.argv[1] = scd->arg[1];
         if (argc > 2) dctx.argv[2] = scd->arg[2];
         if (argc > 3) dctx.argv[3] = scd->arg[3];
         if (argc > 4) dctx.argv[4] = scd->arg[4];
         if (argc > 5) dctx.argv[5] = scd->arg[5];
(Note that the intention to do something like this is already evident in 
parts of the code.)  This change allows us to use the same BPF 
instructions, regardless of the value of argc.

*)  Change the trampoline code to set argc.

*)  Add ARGC relocation code to dt_bpf.c, setting argc to dt_probe_t's 
xargc member.  (There are some notes suggesting that the intention is 
ultimately to use a map at run time to get argc. That would allow more 
probes to use the same BPF program rather than having each probe's 
program have its own hard-wired argc value.  On the other hand, we 
cannot yet attach a shared BPF program to many probes anyhow, so 
hardwiring the value of argc for a probe seems expedient for now.)

I think the fbt trampoline needs similar attention.