All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kris Van Hees <kris.van.hees@oracle.com>
To: Eugene Loh <eugene.loh@oracle.com>
Cc: Kris Van Hees <kris.van.hees@oracle.com>,
	dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH] fbt: implement return value support for fexit-based FBT return probes
Date: Thu, 1 Aug 2024 14:56:03 -0400	[thread overview]
Message-ID: <ZqvaQ6LXDoRKihfj@oracle.com> (raw)
In-Reply-To: <606808dc-172f-5518-7734-739dfed0a781@oracle.com>

On Thu, Aug 01, 2024 at 02:15:17PM -0400, Eugene Loh wrote:
> Reviewed-by: Eugene Loh <eugene.loh@oracle.com>
> with a few nits...
> 
> On 8/1/24 10:24, Kris Van Hees wrote:
> > On Thu, Aug 01, 2024 at 01:49:35AM -0400, Eugene Loh wrote:
> > > Is there a test?
> > Yes, the testsuite already contains a test (tst.return1.d) whose failure
> > prompted the need for this patch.  And with the patch, it passes.
> 
> Thanks.  So the earlier culprit/insufficient patch (fe2101e5) went out in
> the last release with this test... failing?  Not tested (on fentry systems,
> where it makes a difference)?  A known failure in the last release?  (I
> forget.)

Well, against all odds it actually "works" on older kernels with the quite
insufficient patch because by total coincidence the right value happens to be
present in the correct arg slot.

> > > On 8/1/24 01:19, Kris Van Hees wrote:
> > > > Commit fe2101e5 ("fbt: implement based on fentry/fexit probes") failed
> > > > to provide a proper implementation to pass the function return value as
> > > > arg1 for FBT return probes based on fexit probes.
> > > > 
> > > > Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
> > > > ---
> > > >    libdtrace/dt_prov_fbt.c | 20 +++++++++++++++++++-
> > > >    1 file changed, 19 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/libdtrace/dt_prov_fbt.c b/libdtrace/dt_prov_fbt.c
> > > > index fa888ed8..99b42586 100644
> > > > --- a/libdtrace/dt_prov_fbt.c
> > > > +++ b/libdtrace/dt_prov_fbt.c
> > > > @@ -172,6 +172,7 @@ static int populate(dtrace_hdl_t *dtp)
> > > >     */
> > > >    static int fprobe_trampoline(dt_pcb_t *pcb, uint_t exitlbl)
> > > >    {
> > > > +	dtrace_hdl_t	*dtp = pcb->pcb_hdl;
> > > >    	dt_irlist_t	*dlp = &pcb->pcb_ir;
> > > >    	dt_probe_t	*prp = pcb->pcb_probe;
> > > > @@ -185,6 +186,8 @@ static int fprobe_trampoline(dt_pcb_t *pcb, uint_t exitlbl)
> > > >    			emit(dlp, BPF_STORE(BPF_DW, BPF_REG_7, DMST_ARG(i), BPF_REG_0));
> > > >    		}
> > > >    	} else {
> > > > +		dt_module_t	*dmp;
> > > > +
> > > >    		/*
> > > >    		 * fbt:::return arg0 should be the function offset for the
> > > >    		 * return instruction.  The fexit prpbe fires at a point where
> 
> Might as well s/prpbe/probe/ while we're here.

Good catch.

> > > > @@ -194,6 +197,21 @@ static int fprobe_trampoline(dt_pcb_t *pcb, uint_t exitlbl)
> > > >    		 */
> > > >    		dt_cg_xsetx(dlp, NULL, DT_LBL_NONE, BPF_REG_0, -1);
> > > >    		emit(dlp,  BPF_STORE(BPF_DW, BPF_REG_7, DMST_ARG(0), BPF_REG_0));
> > > > +
> > > > +		/*
> > > > +		 * The return value is provided by the fexit probe as an
> > > > +		 * argument slot past the last function argument.  We can get
> > > > +		 * the number of function arguments using the BTF id that has
> > > > +		 * been stored as the tracepoint event id.
> > > > +		 */
> > > > +		dmp = dt_module_lookup_by_name(dtp, prp->desc->mod);
> > > > +		if (dmp != NULL) {
> > > > +			int32_t	btf_id = dt_tp_get_event_id(prp);
> > > > +			int	i = dt_btf_func_argc(dtp, dmp->dm_btf, btf_id);
> > > > +
> > > > +			emit(dlp, BPF_LOAD(BPF_DW, BPF_REG_0, BPF_REG_8, i * 8));
> > > > +			emit(dlp, BPF_STORE(BPF_DW, BPF_REG_7, DMST_ARG(1), BPF_REG_0));
> > > > +		}
> 
> I assume we don't worry about the handling of dmp==NULL because it's
> "unlikely" (already been checked) and there's nothing more sensible to do
> anyhow?  Or load arg1 with 0xdeadbeef or something?

Unpredictable result is probably the best we can do right now.  Any deliberatea
value isn't really any better.
 
We need to look into a future solution to provide proper error reporting
during the trampoline creation.

> > > >    	}
> > > >    	dt_cg_tramp_epilogue(pcb);
> > > > @@ -274,7 +292,7 @@ static int fprobe_prog_load(dtrace_hdl_t *dtp, const dt_probe_t *prp,
> > > >    	dt_module_t			*dmp;
> > > >    	atype = strcmp(desc->prb, "entry") == 0 ? BPF_TRACE_FENTRY
> > > > -						     : BPF_TRACE_FEXIT;
> > > > +						: BPF_TRACE_FEXIT;
> > > >    	dmp = dt_module_lookup_by_name(dtp, desc->mod);
> > > >    	if (dmp == NULL)

      reply	other threads:[~2024-08-01 18:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-01  5:19 [PATCH] fbt: implement return value support for fexit-based FBT return probes Kris Van Hees
2024-08-01  5:49 ` Eugene Loh
2024-08-01 14:24   ` Kris Van Hees
2024-08-01 18:15     ` Eugene Loh
2024-08-01 18:56       ` Kris Van Hees [this message]

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=ZqvaQ6LXDoRKihfj@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.