This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: deferencing variable with embedded C code
Wenji Huang wrote:
> Jun Koi wrote:
> > I am looking at the documentation on embedded C code, and see that to
> > dereference a field of structure (like skb->dev->name), we need to do
> > something like below:
> >
> > struct net_device *dev;
> > char *name;
> > dev = kread(&(skb->dev));
> > name = kread(&(dev->name));
> >
> > Why is that? Because embedded C is running in kernel context, and
> > compiled with kernel code, it has access to all kernel structure, but
> > why it cannot deference structure itself?
>
> This is the safe way to avoid deference of incorrect pointer.
Just to expand a little on this -- we use kread out of paranoia. If
your pointers are all valid, then you certainly could use skb->dev->name
in your embedded code and it would work just fine. However, if a
pointer is bad, then an unprotected read will probably crash the whole
system.
While uncommon, there are still several causes for an embedded-C
function to receive a bad pointer, including incorrect debug
information, paged-out memory, or simple user error. We want it to be
impossible for non-guru users to crash the system, so we need to be very
careful about what pointers we trust.
If you're writing embedded C for your own guru-mode scripts, then you're
welcome to read pointers directly if you think they're safe, and you'll
only have yourself to blame if you're wrong. If that code is in a
tapset though, we have to be prepared for non-guru users to call those
functions with possibly dangerous values, so we protect the dereferences
with kread().
Josh