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: dtrace@lists.linux.dev, dtrace-devel@oss.oracle.com
Subject: Re: [DTrace-devel] [PATCH 2/8] Reduce stack depth if kernel returns NULL frames
Date: Wed, 28 Aug 2024 16:17:18 -0400	[thread overview]
Message-ID: <Zs+FzkKIbqs6HSA6@oracle.com> (raw)
In-Reply-To: <4098cfc6-ce97-e8e4-28c6-b5306c23e51f@oracle.com>

On Wed, Aug 28, 2024 at 04:11:29PM -0400, Eugene Loh wrote:
> It's been a while, but if I remember correctly it's actually just the other
> way around.  That is, to make stack and depth consistent, we're forced into
> this "depth reduction" patch.  Put another way, the stack simply does not
> include NULL pointers -- there is no way to remove them.
> 
> E.g., let's say we have a buffer of 8 pointers and we ask for the stack and
> get back:
> 
>     0xdead 0xbeef 0xfeed 0xface NULL NULL NULL NULL
> 
> Looks like 4 pointers.  But we don't count them.  We just use the return
> value from the helper function.  If it tells us "4", then everything is
> consistent.  But for some reason (I haven't looked at the code to figure out
> why), it can be 5 or even 6.  So this patch bumps that value down -- to
> attain the consistency I think you're asking about.

So you are saying that the number of values that is actually filled in is not
consistent with the return value of the bpf_get_stack() helper?  That would
sound like a kernel bug.

  reply	other threads:[~2024-08-28 20:17 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 ` [PATCH 2/8] Reduce stack depth if kernel returns NULL frames eugene.loh
2024-08-19 23:30   ` [DTrace-devel] " Kris Van Hees
2024-08-28 20:11     ` Eugene Loh
2024-08-28 20:17       ` Kris Van Hees [this message]
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=Zs+FzkKIbqs6HSA6@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.