Tapset difficulties w/ pointers

["Stone, Joshua I" <joshua.i.stone@intel.com>]

Hi all,

In working on the 'process' tapset, I've encountered a few difficulties
that I thought I would share, so we can search the collective mind for
solutions. I've split this into two emails to separate the related
parts...

For the process.exec probe, I would like to make the pointer to the new
task_struct available.  This is fine, and then I can make
access-functions for the user to extract data from this, like so:

  function task_pid:long (task:long) %{ /* pure */
      if (unlikely(THIS->task == 0))
          THIS->__retvalue = 0;
      else {
          struct task_struct *t = (struct task_struct
*)(long)THIS->task;
          THIS->__retvalue = t->tgid;
      }
  %}

The obvious problem here is safety.  I can check that the parameter is
not zero, but what do I do if the user calls task_pid(0xDEADBEEF)?
Oops...  Or what happens if the user stashes the pointer away in a
global, and tries to read it later?  Oops...

One solution is to "hide" task_pid(), perhaps by renaming it to
__task_pid(), and then have the tapset provide variables for pid, tid,
etc. and rely on the compiler to elide those that are unused.  Then the
pointer never needs to be given to the user.  This is still not really
safe though, because that __task_pid() is only discouraged, not
protected.  We probably could play a game with naming that only allows
calling some functions from within the same file, but these functions
would need to be duplicated multiple tapsets needs them.

A more general solution would be if we had some sort of "handle" type.
This might be an abstract data type that the script language is unable
to modify.  It can have metadata to identify the type, and perhaps also
to limit the valid lifetime of the pointer.  I haven't thought through
all of the implementation details, but I think that a handle type would
not be too far a stretch.

I welcome any feedback on this idea, and of course other ideas are
welcome as well.


Josh