[prev in list] [next in list] [prev in thread] [next in thread] 

List:       evlog-developers
Subject:    Re: [evlog-dev] dprobes and event logging.
From:       davole () us ! ibm ! com
Date:       2001-12-12 21:41:59
[Download RAW message or body]


I was using 'log mrf' and i happened to be trying to resolve some 
incorrect addresses.  I could easily get around a NULL pointer dereference 
by checking my address, and then changing my minor number to something 
appropriate and then going ahead and logging.  I thought with all the 
mention of "fault" in dprobes.lang(5) describing 'log mrf' that doing 
"logonfault = no" in the header might suppress logging in the case of an 
error.  I am not sure how much one would really want to suppress these 
messages.  I am not quite clear what type of fault logonfault applies to. 

I'd say rather than make it a command line switch, allow users to modify 
the behaviour in the .rpn file with something similar to the logonfault 
clause.  This could also allow for easier migration to something 
crazy like rpn fault handlers if someone feels it's needed.  A fault 
handler could involve switching up minors and going ahead or suppressing.  
Although a "suppresslogfault = yes" would seem to suffice for now. 


On Tue, 11 Dec 2001, Richard J Moore wrote:

> 
> Hello davido, I'm glad you've played with this. We log a 3-byte prefix +
> 4-byte error code when data is not accessible by the probe handler. And
> this was designed to be used with the dprobes dynamic trace formatter (to
> be released very soon) that hooks into Linux Trace Toolkit. However you
> raise in interesting point: should we provide a command line switch to
> suppress logging the prefix bytes and error codes? I think this is probably
> not a bad idea. The result will then be that nothing is logged if data is
> not available and that may confuse other formatters less. What do you
> think?
> 
> Richard
> 
> 
> Richard Moore -  RAS Project Lead - Linux Technology Centre (ATS-PIC).
> http://oss.software.ibm.com/developerworks/opensource/linux
> Office: (+44) (0)1962-817072, Mobile: (+44) (0)7768-298183
> IBM UK Ltd,  MP135 Galileo Centre, Hursley Park, Winchester, SO21 2JN, UK
> 
> 
> 
> davido@beaverton.ibm.com                                                            \
>  Sent by:                                 To:     \
> <evlog-developers@lists.sourceforge.net>                           \
> evlog-developers-admin@lists.sourc       cc:                                        \
>  eforge.net                               Subject:     [evlog-dev] dprobes and \
> event logging.                        
> 
> 11/12/2001 02:30                                                                    \
>  Please respond to davido                                                           \
>  
> 
> 
> 
> 
> So i have been tinkering around with using event logging and dprobes
> together in the same kerel.  They turn out to be a very powerful
> combination if one makes use of the templates infrastructure.  One can log
> whole structures from dprobes and then use the templates for formatting
> them out nicely.  This works great for tracing function calls in the
> kernel and allows you to poke at their arguments after the fact.
> 
> One interesting point though is that if a dprobes command fails, it will
> log a different structure which will then cause the template arranged for
> the facility.severity to fail.  For instance, if i was logging the inode
> passed into a function call and the inode is NULL, the dprobes logged data
> will end up being something like 5 error bytes...a little smaller than an
> inode.  I don't really thing it would be necessary to add logic to the
> evlog to handle this case, since we should always be able to switch up our
> event type before we log for these cases.  I only mention it to keep
> peoples brains active as to the situations evlog can encounter.
> 
> I tried defining two templates in the same file for the same
> characteristic (facility.event_type).  It compiles without error with
> the second template over-riding the first (logically enough) but i can
> see artifacts of the first template in the the binary .to file.  This seems
> 
> to be benign though it probably would be wise to avoid.  It's probably
> some sprintf silliness and i really didn't feel like figuring out how all
> the template code worked.
> 
> daveo
> 
> 
> 
> _______________________________________________
> evlog-developers mailing list
> evlog-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/evlog-developers
> 
> 
> 
> 
> 
> _______________________________________________
> evlog-developers mailing list
> evlog-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/evlog-developers
> 


_______________________________________________
evlog-developers mailing list
evlog-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/evlog-developers


[prev in list] [next in list] [prev in thread] [next in thread]