Linux DTrace development list
 help / color / mirror / Atom feed
From: Nick Alcock <nick.alcock@oracle.com>
To: eugene.loh@oracle.com
Cc: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [PATCH 01/14] Fix stack-skip counts for caller and stackdepth
Date: Fri, 13 Jun 2025 15:33:33 +0100	[thread overview]
Message-ID: <87sek3d83m.fsf@esperi.org.uk> (raw)
In-Reply-To: <20250522180118.27343-1-eugene.loh@oracle.com> (eugene loh's message of "Thu, 22 May 2025 14:01:05 -0400")

On 22 May 2025, eugene loh told this:

> From: Eugene Loh <eugene.loh@oracle.com>
>
> Apparently, when we call the BPF get_stack() helper function,
> it generally knows how many frames to skip to get the real kernel
> stack.  For fentry/fexit, however, this is apparently not the case,
> and commit bc65cb44d
> ("cg: allow providers to specify a skip count for stack retrieval")
> added the ability to skip frames for fentry/fexit probes.
>
> When this "skip" is needed, however, it must must be even deeper
> when we descend further frames, such as when we call dt_bpf_*()
> precompiled functions.

Ack.

> Add this support for dt_bpf_caller() and dt_bpf_stackdepth().
> That is, if there are stack-skip frames, skip yet one more frame
> when inside a bpf/get_bvar.c function.

The general approach here seems sound, but this confuses me. Is the
assumption that if the skip is not needed, get_stack() will itself know
how many frames to skip, and will skip dt_dt_bvar_caller() for you?

(So a zero skip is actually a "the system knows", and a nonzero skip
causes the system to not skip anything, so you have to do all the
skipping yourself?

This behaviour is not documented in bpf_get_stack()'s documentation,
which absolutely does not mean it doesn't do it...)

> Note that we declare the skip count volatile.  The compiler might
> optimize code that uses the STACK_SKIP value, but we will subsequently
> perform relocations that adjust this value.

... why doesn't this apply to every other extern global variable in
get_bvar()? They're all similarly relocated...

> Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
> ---
>  bpf/get_bvar.c | 17 ++++++++++++++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/bpf/get_bvar.c b/bpf/get_bvar.c
> index 9625e764e..99a6503d5 100644
> --- a/bpf/get_bvar.c
> +++ b/bpf/get_bvar.c
> @@ -53,12 +53,17 @@ noinline uint64_t dt_bvar_args(const dt_dctx_t *dctx, uint32_t idx)
>  
>  noinline uint64_t dt_bvar_caller(const dt_dctx_t *dctx)
>  {
> -	uint64_t	buf[2] = { 0, };
> +	uint64_t	buf[3] = { 0, };
> +	volatile uint64_t
> +			skip = (uint64_t)(&STACK_SKIP);
>  
>  	if (bpf_get_stack(dctx->ctx, buf, sizeof(buf),
> -			  (uint64_t)(&STACK_SKIP) & BPF_F_SKIP_FIELD_MASK) < 0)
> +			  skip & BPF_F_SKIP_FIELD_MASK) < 0)
>  		return 0;
>  
> +	/* If we had to skip any frames, account for the dt_bvar_caller() frame. */
> +	if (skip)
> +		return buf[2];
>  	return buf[1];
>  }
>  
> @@ -203,9 +208,11 @@ noinline uint64_t dt_bvar_stackdepth(const dt_dctx_t *dctx)
>  	uint32_t	bufsiz = (uint32_t) (uint64_t) (&STKSIZ);
>  	char		*buf = dctx->mem + (uint64_t)(&STACK_OFF);
>  	uint64_t	retv;
> +	volatile uint64_t
> +			skip = (uint64_t)(&STACK_SKIP);
>  
>  	retv = bpf_get_stack(dctx->ctx, buf, bufsiz,
> -			     (uint64_t)(&STACK_SKIP) & BPF_F_SKIP_FIELD_MASK);
> +			     skip & BPF_F_SKIP_FIELD_MASK);
>  	if (retv < 0)
>  		return error(dctx, DTRACEFLT_BADSTACK, 0 /* FIXME */);
>  
> @@ -217,7 +224,11 @@ noinline uint64_t dt_bvar_stackdepth(const dt_dctx_t *dctx)
>  	 * If retv==bufsiz, presumably the stack is larger than what we
>  	 * can retrieve.  But it's also possible that the buffer was exactly
>  	 * large enough.  So, leave it to the user to interpret the result.
> +	 *
> +	 * If we had to skip any frames, account for the dt_bvar_stackdepth() frame.
>  	 */
> +	if (skip)
> +		return retv / sizeof(uint64_t) - 1;
>  	return retv / sizeof(uint64_t);
>  }

-- 
NULL && (void)

  parent reply	other threads:[~2025-06-13 14:33 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-22 18:01 [PATCH 01/14] Fix stack-skip counts for caller and stackdepth eugene.loh
2025-05-22 18:01 ` [PATCH 02/14] Add stack-skip frame count for rawtp provider eugene.loh
2025-06-13 14:35   ` Nick Alcock
2025-05-22 18:01 ` [PATCH 03/14] Test: remove unnecessary "unstable" tag eugene.loh
2025-06-13 14:35   ` [DTrace-devel] " Nick Alcock
2025-05-22 18:01 ` [PATCH 04/14] Test: caller and stackdepth tests for fbt provider eugene.loh
2025-06-13 14:40   ` [DTrace-devel] " Nick Alcock
2025-06-16 19:43     ` Eugene Loh
2025-06-25  4:14       ` Kris Van Hees
2025-05-22 18:01 ` [PATCH 05/14] Test: caller and stackdepth tests for dtrace provider eugene.loh
2025-06-13 14:42   ` Nick Alcock
2025-05-22 18:01 ` [PATCH 06/14] Test: caller and stackdepth tests for rawtp provider eugene.loh
2025-06-13 14:45   ` Nick Alcock
2025-05-22 18:01 ` [PATCH 07/14] Test: caller and stackdepth tests for cpc provider eugene.loh
2025-06-13 14:48   ` [DTrace-devel] " Nick Alcock
2025-05-22 18:01 ` [PATCH 08/14] Test: caller and stackdepth tests for ip provider eugene.loh
2025-06-13 14:51   ` [DTrace-devel] " Nick Alcock
2025-06-17  3:38     ` Eugene Loh
2025-06-25  4:15       ` Kris Van Hees
2025-05-22 18:01 ` [PATCH 09/14] Test: caller and stackdepth tests for profile provider eugene.loh
2025-06-13 14:52   ` [DTrace-devel] " Nick Alcock
2025-05-22 18:01 ` [PATCH 10/14] Test: caller and stackdepth tests for sched provider eugene.loh
2025-06-13 14:52   ` Nick Alcock
2025-05-22 18:01 ` [PATCH 11/14] Test: caller and stackdepth tests for proc provider eugene.loh
2025-06-13 14:53   ` Nick Alcock
2025-06-15 17:50     ` Eugene Loh
2025-06-19 12:52       ` Nick Alcock
2025-06-25  4:18       ` Kris Van Hees
2025-05-22 18:01 ` [PATCH 12/14] Test: caller and stackdepth tests for rawfbt provider eugene.loh
2025-06-13 14:54   ` [DTrace-devel] " Nick Alcock
2025-06-17 23:17     ` Eugene Loh
2025-05-22 18:01 ` [PATCH 13/14] Test: caller and stackdepth tests for io provider eugene.loh
2025-06-13 14:56   ` [DTrace-devel] " Nick Alcock
2025-05-22 18:01 ` [PATCH 14/14] Test: caller and stackdepth tests for lockstat provider eugene.loh
2025-06-13 14:57   ` Nick Alcock
2025-06-13 14:33 ` Nick Alcock [this message]
2025-06-16 19:21   ` [PATCH 01/14] Fix stack-skip counts for caller and stackdepth Eugene Loh
2025-06-19 13:03     ` Nick Alcock
2025-06-19 16:20       ` Kris Van Hees
2025-06-19 16:32         ` Kris Van Hees
2025-06-23 14:04           ` Nick Alcock

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=87sek3d83m.fsf@esperi.org.uk \
    --to=nick.alcock@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