All of lore.kernel.org
 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 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.