public inbox for dtrace@lists.linux.dev
 help / color / mirror / Atom feed
From: eugene.loh@oracle.com
To: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: [PATCH 2/8] Reduce stack depth if kernel returns NULL frames
Date: Tue,  4 Jun 2024 14:00:02 -0400	[thread overview]
Message-ID: <20240604180008.11331-2-eugene.loh@oracle.com> (raw)
In-Reply-To: <20240604180008.11331-1-eugene.loh@oracle.com>

From: Eugene Loh <eugene.loh@oracle.com>

The return value from the BPF helper function bpf_get_stack()
basically returns the size of the stack returned.  We use this
value to report stack depth.

Some of the top frames can be NULL, however, leading to some
inconsistencies between reported stacks and stack depths.

Add some code to reduce the stack depth if one or two top
frames are NULL.

There is an existing test to check for this problem.  It will
appear in a later patch since it has multiple problems.

Signed-off-by: Eugene Loh <eugene.loh@oracle.com>
---
 bpf/get_bvar.c | 17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)

diff --git a/bpf/get_bvar.c b/bpf/get_bvar.c
index ea5dc6b1..a0c04f3a 100644
--- a/bpf/get_bvar.c
+++ b/bpf/get_bvar.c
@@ -67,7 +67,9 @@ noinline uint64_t dt_get_bvar(const dt_dctx_t *dctx, uint32_t id, uint32_t idx)
 		uint32_t bufsiz = (uint32_t) (uint64_t) (&STKSIZ);
 		uint64_t flags;
 		char *buf = dctx->mem + (uint64_t)(&STACK_OFF);
-		uint64_t stacksize;
+		int64_t stacksize;
+		int64_t topslot;
+		uint64_t *pcs = (uint64_t *)buf;
 
 		if (id == DIF_VAR_USTACKDEPTH)
 			flags = BPF_F_USER_STACK;
@@ -87,8 +89,19 @@ noinline uint64_t dt_get_bvar(const dt_dctx_t *dctx, uint32_t id, uint32_t idx)
 		 * 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.
+		 *
+		 * The helper function also sometimes returns some empty frames
+		 * at the top.  Bump the depth down some so that the stack depth
+		 * we report is consistent with the number of frames returned.
+		 * Arguably, this should be fixed in the kernel, but we can
+		 * work around the problem for now.
 		 */
-		return stacksize / sizeof(uint64_t);
+		topslot = stacksize / sizeof(uint64_t) - 1;
+		if (topslot >= 0 && topslot < (bufsiz / sizeof(uint64_t)) && pcs[topslot] == 0)
+			topslot--;
+		if (topslot >= 0 && topslot < (bufsiz / sizeof(uint64_t)) && pcs[topslot] == 0)
+			topslot--;
+		return topslot + 1;
 	}
 	case DIF_VAR_CALLER:
 	case DIF_VAR_UCALLER: {
-- 
2.18.4


  reply	other threads:[~2024-06-04 18:00 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-04 18:00 [PATCH 1/8] test: Allow aggpercpu test to omit some CPUs eugene.loh
2024-06-04 18:00 ` eugene.loh [this message]
2024-08-19 23:30   ` [DTrace-devel] [PATCH 2/8] Reduce stack depth if kernel returns NULL frames Kris Van Hees
2024-08-28 20:11     ` Eugene Loh
2024-08-28 20:17       ` Kris Van Hees
2024-08-28 20:23         ` Eugene Loh
2024-08-28 20:37           ` Kris Van Hees
2025-08-13  5:12             ` Eugene Loh
2024-06-04 18:00 ` [PATCH 3/8] test: Fix nonexistent @@sort option eugene.loh
2024-08-19 23:15   ` [DTrace-devel] " Kris Van Hees
2024-06-04 18:00 ` [PATCH 4/8] test: Remove unneeded -w option eugene.loh
2024-08-19 23:12   ` [DTrace-devel] " Kris Van Hees
2024-06-04 18:00 ` [PATCH 5/8] Fix stddev() carryover computation eugene.loh
2024-08-19 23:13   ` [DTrace-devel] " Kris Van Hees
2024-06-04 18:00 ` [PATCH 6/8] test: Check dtrace return status eugene.loh
2024-06-04 18:00 ` [PATCH 7/8] Clean up double semicolons eugene.loh
2024-08-19 23:34   ` [DTrace-devel] " Kris Van Hees
2024-06-04 18:00 ` [PATCH 8/8] Turn some leading spaces into tabs eugene.loh
2024-08-19 23:34   ` [DTrace-devel] " Kris Van Hees
2024-08-19 23:11 ` [PATCH 1/8] test: Allow aggpercpu test to omit some CPUs 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=20240604180008.11331-2-eugene.loh@oracle.com \
    --to=eugene.loh@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    /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