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)
next prev 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