[DTrace-devel] [PATCH v2 01/02] ERROR probe implementation

Eugene Loh eugene.loh at oracle.com
Sat Mar 27 20:29:53 PDT 2021


Oops.  I overlooked this post.

It seems to me that there were a number of issues we discussed in 
previous emails that are still leftover here.  Some of the issues are 
discussed at 
https://oss.oracle.com/pipermail/dtrace-devel/2021-January/000929.html 
in case you need a refresher.  I certainly did!

Then Reviewed-by: Eugene Loh <eugene.loh at oracle.com>

On 3/19/21 12:53 AM, Kris Van Hees wrote:
> The ERROR probe is special because it is not associated with a system
> event.  Instead, it is a 'fake' probe that is reported whenever there
> a fault occurs during probe execution.  This can be implemented in
> BPF by including the ERROR probe clauses in every probe program that
> needs them.
>
> Whenever a fault occurs in one of our BPF programs, a call is made to
> dt_probe_error() to record data associated with the fault, and the
> clause is terminated with a non-zero return value.  The data items
> that can be set are:
>
> 	- offset in the clause at which the fault occurred
> 	- fault type
> 	- value
>
> When a clause ends with a non-zero return value, execution is directed
> to the ERROR probe clauses that are included in each probe program that
> needs them.  These clauses are compiled as regular probe clauses, but
> they are processed separately to resolve the EPID and PRID identifiers
> according to the ERROR probe rather than the probe that the clauses are
> included for.
>
> (Special thanks to Eugene Loh for his review comments - various fixes
>   he implemented got integrated into this patch.)
>
> Signed-off-by: Kris Van Hees <kris.van.hees at oracle.com>
> Signed-off-by: Eugene Loh <eugene.loh at oracle.com>



More information about the DTrace-devel mailing list