[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