public inbox for dtrace@lists.linux.dev
 help / color / mirror / Atom feed
From: Kris Van Hees <kris.van.hees@oracle.com>
To: Eugene Loh <eugene.loh@oracle.com>
Cc: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH 05/22] Set the ERROR PRID in BPF code
Date: Fri, 6 Sep 2024 22:03:38 -0400	[thread overview]
Message-ID: <Ztu0ehrOeHqwIvmG@oracle.com> (raw)
In-Reply-To: <d009801f-28e4-3b69-3f2f-ae99b577c1bd@oracle.com>

On Fri, Sep 06, 2024 at 09:25:12PM -0400, Eugene Loh wrote:
> On 9/6/24 20:20, Kris Van Hees wrote:
> 
> > On Thu, Aug 29, 2024 at 01:22:02AM -0400, eugene.loh@oracle.com wrote:
> > > From: Eugene Loh <eugene.loh@oracle.com>
> > > 
> > > We use the fact that the ERROR PRID is always 3.
> > Where do we use it?  We certainly should never override the probe id that is
> > assigned by dtrace when providers provide probes.  Will it always be 3?  Almost
> > certainly, yes.  But the right way to do this is to actually make the ERROR
> > PRID available as a symbol that can be resolved at program load time, so that
> > the dt_probe_error function can get to its value.
> 
> I'm confused?  I thought I did this and you suggested simply hardwiring the
> value 3. https://oss.oracle.com/pipermail/dtrace-devel/2024-July/004989.html

True, though I didn't mean to just hardwire the value 3.  At a minimum, I think
it ought to be a define to set the value of the BEGIN, END, and ERROR probe,
so that a symbolic name can be used in code.  And that probably would mean that
it is best to add a check in the dtrace provider to ensure that those are
indeed the probe ids assigned to BEGIN/END/ERROR (and if not, something is very
wrong).

> > Anyway, the need to restore the mst->prid value in this patch also highlights
> > that there is a much bigger problem...  A fault in one clause contaminates the
> > first 6 arguments of the probe, and since a fault only interrupts the execution
> > of the current clause, following clauses will no longer see the correct values
> > of the first 6 arguments but rather the ones that dt_probe_error() stored in
> > mst->argv[0 .. 5].  That is a bug for sure!
> 
> Good point, but... a separate issue/patch?

Yes, already written :)

> > Here is a test that demonstrates this issue:
> > 
> > #pragma D option quiet
> > 
> > syscall::write*:entry
> > {
> > 	self->arg0 = arg0;
> > 	self->arg1 = arg1;
> > 	self->arg2 = arg2;
> > 	self->arg3 = arg3;
> > 	self->arg4 = arg4;
> > 	self->arg5 = arg5;
> > 
> > 	printf("%d / %d / %d / %d / %d / %d\n",
> > 	       arg0, arg1, arg2, arg3, arg4, arg5);
> > }
> > 
> > syscall::write*:entry
> > {
> > 	trace(*(int *)0);
> > }
> > 
> > syscall::write*:entry,
> > ERROR {
> > 	printf("%d / %d / %d / %d / %d / %d\n",
> > 	       arg0, arg1, arg2, arg3, arg4, arg5);
> > }
> > 
> > syscall::write*:entry
> > {
> > 	exit(self->arg0 != arg0 || self->arg1 != arg1 || self->arg2 != arg2 ||
> > 	     self->arg3 != arg3 || self->arg4 != arg4 || self->arg5 != arg5
> > 		? 1 : 0);
> > }
> > 
> > So, we need the ERROR prid value exposed as an external symbol so that it can
> > be used in dt_probe_error(), and a patch that fixes the contamination of the
> > arg values.
> > 
> > > Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> > > ---
> > >   bpf/probe_error.c                         |  3 +++
> > >   test/unittest/builtinvar/tst.id_ERROR.d   | 32 +++++++++++++++++++++++
> > >   test/unittest/builtinvar/tst.id_ERROR.r   |  3 +++
> > >   test/unittest/builtinvar/tst.id_ERROR.r.p |  4 +++
> > >   4 files changed, 42 insertions(+)
> > >   create mode 100644 test/unittest/builtinvar/tst.id_ERROR.d
> > >   create mode 100644 test/unittest/builtinvar/tst.id_ERROR.r
> > >   create mode 100755 test/unittest/builtinvar/tst.id_ERROR.r.p
> > > 
> > > diff --git a/bpf/probe_error.c b/bpf/probe_error.c
> > > index c8ddcdfa..ee1a1793 100644
> > > --- a/bpf/probe_error.c
> > > +++ b/bpf/probe_error.c
> > > @@ -26,6 +26,7 @@ noinline void dt_probe_error(const dt_dctx_t *dctx, uint64_t pc, uint64_t fault,
> > >   			     uint64_t illval)
> > >   {
> > >   	dt_mstate_t	*mst = dctx->mst;
> > > +	int		oldprid = mst->prid;
> > >   	mst->argv[0] = 0;
> > >   	mst->argv[1] = mst->epid;
> > > @@ -34,7 +35,9 @@ noinline void dt_probe_error(const dt_dctx_t *dctx, uint64_t pc, uint64_t fault,
> > >   	mst->argv[4] = fault;
> > >   	mst->argv[5] = illval;
> > > +	mst->prid = 3;
> > >   	dt_error(dctx);
> > > +	mst->prid = oldprid;
> > >   	mst->fault = fault;
> > >   }
> > > diff --git a/test/unittest/builtinvar/tst.id_ERROR.d b/test/unittest/builtinvar/tst.id_ERROR.d
> > > new file mode 100644
> > > index 00000000..59021c60
> > > --- /dev/null
> > > +++ b/test/unittest/builtinvar/tst.id_ERROR.d
> > > @@ -0,0 +1,32 @@
> > > +/*
> > > + * Oracle Linux DTrace.
> > > + * Copyright (c) 2024, Oracle and/or its affiliates. All rights reserved.
> > > + * Licensed under the Universal Permissive License v 1.0 as shown at
> > > + * http://oss.oracle.com/licenses/upl.
> > > + */
> > > +
> > > +/*
> > > + * ASSERTION:
> > > + * The id in the ERROR probe is 3.
> > > + *
> > > + * SECTION: Variables/Built-in Variables
> > > + */
> > > +
> > > +#pragma D option quiet
> > > +
> > > +tick-1s
> > > +{
> > > +	/* trigger the ERROR probe */
> > > +	trace(*((int*)0));
> > > +}
> > > +
> > > +tick-2s
> > > +{
> > > +	exit(1);
> > > +}
> > > +
> > > +ERROR
> > > +{
> > > +	printf("id of the ERROR probe = %d\n", id);
> > > +	exit(0);
> > > +}
> > > diff --git a/test/unittest/builtinvar/tst.id_ERROR.r b/test/unittest/builtinvar/tst.id_ERROR.r
> > > new file mode 100644
> > > index 00000000..95974abe
> > > --- /dev/null
> > > +++ b/test/unittest/builtinvar/tst.id_ERROR.r
> > > @@ -0,0 +1,3 @@
> > > +id of the ERROR probe = 3
> > > +
> > > +-- @@stderr --
> > > diff --git a/test/unittest/builtinvar/tst.id_ERROR.r.p b/test/unittest/builtinvar/tst.id_ERROR.r.p
> > > new file mode 100755
> > > index 00000000..884b43f4
> > > --- /dev/null
> > > +++ b/test/unittest/builtinvar/tst.id_ERROR.r.p
> > > @@ -0,0 +1,4 @@
> > > +#!/usr/bin/gawk -f
> > > +
> > > +# Drop the line with run-dependent PRID for profile probe.
> > > +!/error on enabled probe ID/ { print }
> > > -- 
> > > 2.43.5
> > > 

  reply	other threads:[~2024-09-07  2:03 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-29  5:21 [PATCH 01/22] test: Handle dtrace:::ERROR arg3 specially eugene.loh
2024-08-29  5:21 ` [PATCH 02/22] test: Clean up tests still expecting obsolete "at DIF offset NN" eugene.loh
2024-08-29  5:22 ` [PATCH 03/22] Action clear() should clear only one aggregation eugene.loh
2024-09-06 21:43   ` Kris Van Hees
2024-08-29  5:22 ` [PATCH 04/22] Remove unused "next" arg from dt_flowindent() eugene.loh
2024-09-06 22:01   ` Kris Van Hees
2024-08-29  5:22 ` [PATCH 05/22] Set the ERROR PRID in BPF code eugene.loh
2024-09-07  0:20   ` Kris Van Hees
2024-09-07  1:25     ` Eugene Loh
2024-09-07  2:03       ` Kris Van Hees [this message]
2024-09-12 20:33         ` Kris Van Hees
2024-09-13 17:21           ` Eugene Loh
2024-08-29  5:22 ` [PATCH 06/22] Fix provider lookup to use prv not prb eugene.loh
2024-09-13 20:01   ` Kris Van Hees
2024-08-29  5:22 ` [PATCH 07/22] Supply a default probe_info() eugene.loh
2024-09-14  0:31   ` Kris Van Hees
2024-09-14  1:59     ` Kris Van Hees
2024-08-29  5:22 ` [PATCH 08/22] dtprobed: Fix comment typo eugene.loh
2024-09-14 15:41   ` Kris Van Hees
2024-08-29  5:22 ` [PATCH 09/22] Clean up dtsd_* members eugene.loh
2024-09-14 15:40   ` Kris Van Hees
2024-08-29  5:22 ` [PATCH 10/22] Simplify dtrace_stmt_create() attr init eugene.loh
2024-09-14 16:25   ` Kris Van Hees
2024-09-14 16:32     ` [DTrace-devel] " Kris Van Hees
2024-09-19 17:38       ` Eugene Loh
2024-09-19 17:42         ` Kris Van Hees
2024-08-29  5:22 ` [PATCH 11/22] DTPPT_POST_OFFSETS is unused eugene.loh
2024-09-14 16:35   ` Kris Van Hees
2024-08-29  5:22 ` [PATCH 12/22] Remove apparently redundant assignment eugene.loh
2024-09-14 16:37   ` Kris Van Hees
2024-08-29  5:22 ` [PATCH 13/22] Eliminate unused args to dt_spec_buf_add_data() eugene.loh
2024-09-14 17:06   ` Kris Van Hees
2024-08-29  5:22 ` [PATCH 14/22] Both dted_uarg and dofe_uarg are unused eugene.loh
2024-09-14 17:08   ` Kris Van Hees
2024-08-29  5:22 ` [PATCH 15/22] test: Clean up the specsize tests eugene.loh
2024-09-14 17:57   ` Kris Van Hees
2024-08-29  5:22 ` [PATCH 16/22] test: Fix the speculative tests that checked bufsize eugene.loh
2024-09-14 18:00   ` Kris Van Hees
2024-08-29  5:22 ` [PATCH 17/22] test: Tweak spec sizes to bracket size jumps more narrowly eugene.loh
2024-09-14 18:07   ` Kris Van Hees
2024-09-17 18:05     ` Eugene Loh
2024-08-29  5:22 ` [PATCH 18/22] test: Remove tst.DTRACEFLT_BADADDR2.d dependency on specific PC eugene.loh
2024-09-14 18:10   ` Kris Van Hees
2024-08-29  5:22 ` [PATCH 19/22] test: Fix tst.probestar.d trigger eugene.loh
2024-09-14 18:13   ` Kris Van Hees
2024-10-17 22:53     ` Eugene Loh
2024-08-29  5:22 ` [PATCH 20/22] test: Annotate some XFAILs eugene.loh
2024-09-14 18:29   ` Kris Van Hees
2024-08-29  5:22 ` [PATCH 21/22] test: Fix DIRNAME eugene.loh
2024-08-29 20:25   ` [DTrace-devel] " Sam James
2024-09-14 18:43   ` Kris Van Hees
2024-08-29  5:22 ` [PATCH 22/22] test: Update tst.newprobes.sh xfail message eugene.loh
2024-09-14 18:45   ` Kris Van Hees
2024-08-29 15:57 ` [PATCH 01/22] test: Handle dtrace:::ERROR arg3 specially Kris Van Hees

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Ztu0ehrOeHqwIvmG@oracle.com \
    --to=kris.van.hees@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=eugene.loh@oracle.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox