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]

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


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