BPF List
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Paul Chaignon" <paul.chaignon@gmail.com>
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 3/3] veristat: Report max stack depth
Date: Thu, 14 May 2026 10:06:59 +0000	[thread overview]
Message-ID: <20260514100659.C9938C2BCB3@smtp.kernel.org> (raw)
In-Reply-To: <b3459e61c408daef30d82272f1eacc6399844896.1778689025.git.paul.chaignon@gmail.com>

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] The MEMORY_PEAK statistic is silently truncated from the default CSV output.
- [Medium] The commit message incorrectly claims that the max stack depth 'is null for rejected programs', but the code outputs '0'.
--

commit 407a4af46d427010feeebda3a91736b7ef774219
Author: Paul Chaignon <paul.chaignon@gmail.com>

veristat: Report max stack depth

This patch adds a new "Max stack depth" field to the set of gathered statistics.
It reports the maximum combined stack depth compared to the 512 bytes limit.

>     This patch adds a new "Max stack depth" field to the set of gathered
>     statistics. This field reports the maximum combined stack depth compared
>     to the 512 bytes limit. It is null for rejected programs.

Is the last sentence accurate? The code appears to output 0 instead of "null"
for rejected programs.

When a program is rejected and the log stops early, MAX_STACK remains
zero-initialized. In prepare_value(), MAX_STACK falls back to outputting 0:

	case MAX_STACK:
	case SIZE:
	case JITED_SIZE:
	case MEMORY_PEAK:
		*val = s ? s->stats[id] : 0;
		break;

Furthermore, outputting "null" would fail in parse_stat_value() during replay
mode, as it strictly expects an integer.

> diff --git a/tools/testing/selftests/bpf/veristat.c b/tools/testing/selftests/bpf/veristat.c
> index 5c82950e6978e..9a2275d19ee1b 100644
> --- a/tools/testing/selftests/bpf/veristat.c
> +++ b/tools/testing/selftests/bpf/veristat.c

[ ... ]

> @@ -795,7 +796,7 @@ static const struct stat_specs default_csv_output_spec = {
>  		TOTAL_INSNS, TOTAL_STATES, PEAK_STATES,
>  		MAX_STATES_PER_INSN, MARK_READ_MAX_LEN,
>  		SIZE, JITED_SIZE, PROG_TYPE, ATTACH_TYPE,
> -		STACK, MEMORY_PEAK,
> +		STACK, MAX_STACK, MEMORY_PEAK,
>  	},
>  };

Does this change truncate the MEMORY_PEAK statistic from the default CSV output?

Looking at the full definition of default_csv_output_spec:

static const struct stat_specs default_csv_output_spec = {
	.spec_cnt = 15,
	.ids = {
		FILE_NAME, PROG_NAME, VERDICT, DURATION,
		TOTAL_INSNS, TOTAL_STATES, PEAK_STATES,
		MAX_STATES_PER_INSN, MARK_READ_MAX_LEN,
		SIZE, JITED_SIZE, PROG_TYPE, ATTACH_TYPE,
		STACK, MAX_STACK, MEMORY_PEAK,
	},
};

With MAX_STACK added, there are now 16 elements in the ids array, but spec_cnt
remains hardcoded at 15. Because the formatting loops iterate strictly up to
spec_cnt, it seems the 16th element (MEMORY_PEAK) will be silently ignored,
causing a regression in the generated statistics.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/cover.1778689025.git.paul.chaignon@gmail.com?part=3

      parent reply	other threads:[~2026-05-14 10:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-13 16:27 [PATCH bpf-next v2 0/3] bpf: Maximum combined stack depth Paul Chaignon
2026-05-13 16:28 ` [PATCH bpf-next v2 1/3] bpf: Report maximum " Paul Chaignon
2026-05-14  7:32   ` sashiko-bot
2026-05-13 16:29 ` [PATCH bpf-next v2 2/3] selftests/bpf: Test reported max " Paul Chaignon
2026-05-13 16:30 ` [PATCH bpf-next v2 3/3] veristat: Report " Paul Chaignon
2026-05-13 17:20   ` bot+bpf-ci
2026-05-14 10:06   ` sashiko-bot [this message]

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=20260514100659.C9938C2BCB3@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=paul.chaignon@gmail.com \
    --cc=sashiko-reviews@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