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]

accessing args from return probe


I ran into a problem when considering system call tapsets. There are a significant amount of "getter" system calls that take user space pointer args that are eventually assigned in the function. Heres an example:
asmlinkage long sys_time(int __user * tloc) {
int i;
struct timeval tv;
do_gettimeofday(&tv);
i = tv.tv_sec;
if (tloc) {
if (put_user(i,tloc))
i = -EFAULT;
}
return i;
}


Here is what an appropriate tapset may look like for such a function:

  probe kernel.syscall.time = kernel.function("sys_time") {
     /* nothing to export, the param is
        meaningless to me at this point */
  }

  probe kernel.syscall.time.return =
     kernel.function("sys_time").return {
        /* now that the buf is
           assigned, export it */
        time = get_uint_ptr($tloc);
        retval = get_eax();
     }

This return probe will produce bogus results because by the time the return handler is executed, reference to the arg(s) have been clobbered. This is a problem that must be addressed as this type of behavior is prevalent in system calls.

Here is a workaround using two probes and a global as a record keeper:

global time_tloc_addr

  probe kernel.syscall.time = kernel.function("sys_time") {
     /* save the addr of the arg while I can */
     time_tloc_addr[pid()] = $tloc
  }

  probe kernel.syscall.time.return =
     kernel.function("sys_time").return {
           time = get_uint_ptr(time_tloc_addr[pid()]);
           retval = get_eax();
     }

Indeed, this is ugly. It requires two probes to accomplish one task, and there are globals everywhere. Without changing kprobes, I do not see any other way to get at this data.
I would like peoples thoughts on alternative ways to overcome this challenge. Otherwise I will begin writing tapset code using the aforementioned approach. Of course another method is to simply not allow access to params at the return probe.


Thanks.

--
Kevin Stafford
DES 2 | MS 2M3
Beaverton - OR
Linux Technology Center
IBM Systems & Technology
Phone: 1-503-578-3039
Email: kevinrs@us.ibm.com




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