RE: Pointer chain paranoia

RE: Pointer chain paranoia

[Stone, Joshua I]

On Tuesday, November 14, 2006 1:12 PM, Mike Mason wrote:
> Are pointer chain references in the regular stap language (not
> embedded C) always safe?  In other words, if I use something of the
> form $ptr1->ptr2->ptr3->var, does stap automatically convert that to
> the needed deref() macros? I looked at the resulting module code and
> I think it does, but want to be sure.    

Yes, dereferencing in the script language is guaranteed safe.  If you
find a case where it's not protecting the access, that's a bug.

We really should hold tapsets to the same standard -- unprotected
dereferencing should be treated as a bug.  (Some will be dependent on
bug #3079 though...)

Josh

RE: Pointer chain paranoia

[Stone, Joshua I]

On Tuesday, November 14, 2006 9:15 AM, Mike Mason wrote:
> I'm looking for opinions from the systemtap community... How paranoid
> should we be when following pointer chains in tapsets and scripts?  I
> think we should use deref() unless we're absolutely sure there's no
> chance of referencing a null or bad pointer, but, of course, that'll
> add a lot of code. I'm not sure how you can ever be absolutely sure,
> particularly for longer chains.  What guidance should we give tapset
> and script writers?      
> 
> Mike

I agree with you.  Safety is always more important than efficiency,
especially in tapsets which may be used by non-guru users.  Any
questionable pointers should be carefully dereferenced, e.g., parameters
passed to functions should be assumed bogus.

When a pointer is known to originate from a kernel source, like from
'current' or as a return value from a kernel function, then we might
relax a bit.


Josh

Re: Pointer chain paranoia

[Vara Prasad]

Stone, Joshua I wrote:

>On Tuesday, November 14, 2006 9:15 AM, Mike Mason wrote:
>  
>
>>I'm looking for opinions from the systemtap community... How paranoid
>>should we be when following pointer chains in tapsets and scripts?  I
>>think we should use deref() unless we're absolutely sure there's no
>>chance of referencing a null or bad pointer, but, of course, that'll
>>add a lot of code. I'm not sure how you can ever be absolutely sure,
>>particularly for longer chains.  What guidance should we give tapset
>>and script writers?      
>>
>>Mike
>>    
>>
>
>I agree with you.  Safety is always more important than efficiency,
>especially in tapsets which may be used by non-guru users.  Any
>questionable pointers should be carefully dereferenced, e.g., parameters
>passed to functions should be assumed bogus.
>  
>
I think Murphy's law seem to come true more often than we like, so it is 
better to be paranoid about safety.  If you recollect our OLS 2005 paper 
we stated safety is our top most goal compared to performance, 
especially considering probes are not in hot paths during the production 
run all the time..

>When a pointer is known to originate from a kernel source, like from
>'current' or as a return value from a kernel function, then we might
>relax a bit.
>
>  
>
I am not sure I agree with you to relax a bit with kernel sources at 
this point in our project, may be in the future once we understand the 
usage model better in the field. 

I think it is a good advise to mention in the tapset writers guide to 
use dereference macros before chasing a pointer. I am not sure why one 
should use dereference macros for writing scripts unless you are in guru 
mode (scripts here i mean are end user scripts)..

>Josh
>  
>

Re: Pointer chain paranoia

[Roland McGrath]

The deref macro expands to code that is quite cheap.  The inline code is
just the load instruction about like the compiler would normally generate.
The extra code is in the exception-handling lookaside section, which adds
bloat to the total .ko size but not to the normal module code paths that
will ever be occupying I-cache in normal operation.

Re: Pointer chain paranoia

[Mike Mason]

Are pointer chain references in the regular stap language (not embedded C) always safe?  In other words, if I use something of the form $ptr1->ptr2->ptr3->var, does stap automatically convert that to the needed deref() macros? I looked at the resulting module code and I think it does, but want to be sure.

Mike

Stone, Joshua I wrote:
> On Tuesday, November 14, 2006 9:15 AM, Mike Mason wrote:
>> I'm looking for opinions from the systemtap community... How paranoid
>> should we be when following pointer chains in tapsets and scripts?  I
>> think we should use deref() unless we're absolutely sure there's no
>> chance of referencing a null or bad pointer, but, of course, that'll
>> add a lot of code. I'm not sure how you can ever be absolutely sure,
>> particularly for longer chains.  What guidance should we give tapset
>> and script writers?      
>>
>> Mike
> 
> I agree with you.  Safety is always more important than efficiency,
> especially in tapsets which may be used by non-guru users.  Any
> questionable pointers should be carefully dereferenced, e.g., parameters
> passed to functions should be assumed bogus.
> 
> When a pointer is known to originate from a kernel source, like from
> 'current' or as a return value from a kernel function, then we might
> relax a bit.
> 
> 
> Josh

Re: Pointer chain paranoia

[Roland McGrath]

> Are pointer chain references in the regular stap language (not embedded
> C) always safe?  In other words, if I use something of the form
> $ptr1->ptr2->ptr3->var, does stap automatically convert that to the
> needed deref() macros?

Yes, all generated references use the macro (that's why it exists).

Pointer chain paranoia

[Mike Mason]

I'm looking for opinions from the systemtap community... How paranoid should we be when following pointer chains in tapsets and scripts?  I think we should use deref() unless we're absolutely sure there's no chance of referencing a null or bad pointer, but, of course, that'll add a lot of code. I'm not sure how you can ever be absolutely sure, particularly for longer chains.  What guidance should we give tapset and script writers?

Mike