From: Namhyung Kim <namhyung@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: linux-perf-users@vger.kernel.org
Subject: Re: [PATCH v3 3/3] perf annotate-data: Adjust type offset for flex-array
Date: Tue, 15 Sep 2026 22:58:13 -0700 [thread overview]
Message-ID: <aqov9bkuxh6cNI5F@google.com> (raw)
In-Reply-To: <20260915065313.ECA271F000FF@smtp.kernel.org>
On Tue, Sep 15, 2026 at 06:53:13AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> - [Medium] perf: flex-array offset adjustment skips elements in tail padding
> - [Medium] perf: zero-length flex-arrays bypass element size extraction
> - [Medium] perf: null pointer dereference in find_flex_array() on alloc failure
> --
>
> commit f8d5c159e83503d5c3d85f5f3c22dec6b4f25c06
> Author: Namhyung Kim <namhyung@kernel.org>
>
> perf annotate-data: Adjust type offset for flex-array
>
> This commit adjusts the type offset for flexible array members in perf's
> data annotation. It ensures that the offset is properly adjusted to find
> the corresponding element using modulo operations and updates the member
> name resolution to correctly identify flex arrays.
>
> > diff --git a/tools/perf/util/annotate-data.c b/tools/perf/util/annotate-data.c
> > index 1ee2b74f99205..1c19b807c4f21 100644
> > --- a/tools/perf/util/annotate-data.c
> > +++ b/tools/perf/util/annotate-data.c
> > @@ -241,7 +241,8 @@ static int __add_member_cb(Dwarf_Die *die, void *arg)
> > return DIE_FIND_CB_END;
> >
> > strbuf_init(&sb, 32);
> > - die_get_typename(die, &sb);
> > + if (die_get_typename(die, &sb) < 0)
> > + strbuf_add(&sb, "(unknown type)", 14);
> >
> > __die_get_real_type(die, &member_type);
> > if (dwarf_tag(&member_type) == DW_TAG_typedef)
>
> [Severity: Medium]
> Does this code safely handle zero-length flexible arrays during element size
> extraction?
>
> Just below this change in __add_member_cb(), the logic assumes failures
> for flexible arrays:
>
> if (dwarf_aggregate_size(&die_mem, &size) < 0) {
> if (dwarf_tag(&die_mem) == DW_TAG_array_type) {
> die_get_real_type(&die_mem, &die_mem);
> ...
>
> Since dwarf_aggregate_size() returns 0 for zero-length arrays, the < 0
> condition is skipped. This disables offset adjustment for all GNU zero-length
> arrays (e.g., [0]), which results in incorrect field annotations.
Ok, will handle that too.
>
> [ ... ]
> > @@ -355,15 +377,37 @@ static int fill_member_name(char *buf, size_t sz, struct annotated_member *m,
> [ ... ]
> > +static struct annotated_member *find_flex_array(struct annotated_member *m)
> > +{
> > + struct annotated_member *child;
> > +
> > + if (list_empty(&m->children))
> > + return NULL;
> > +
> > + child = list_last_entry(&m->children, struct annotated_member, node);
> > + if (strstr(child->type_name, "[]"))
>
> [Severity: Medium]
> Could child->type_name be NULL here?
>
> If strbuf_init() or strbuf_add() fails due to memory pressure during type
> string construction, strbuf_detach() returns NULL. Passing an unchecked NULL
> pointer to strstr() in find_flex_array() could cause a segmentation fault in
> the perf tool.
I'll check the return value of strbuf_init(). Then strbuf_add() won't
fail and type_name cannot be NULL.
>
> > + return child;
> > +
> > + return find_flex_array(child);
> > +}
> [ ... ]
> > @@ -1740,6 +1784,7 @@ struct annotated_data_type *find_data_type(struct data_loc_info *dloc)
> [ ... ]
> > - return dso__findnew_data_type(dso, &type_die);
> > + result = dso__findnew_data_type(dso, &type_die);
> > + if (result == NULL)
> > + return NULL;
> > +
> > + if (result->flex_array && dloc->type_offset > result->self.size) {
>
> [Severity: Medium]
> Does this condition skip elements located in the tail padding of the struct?
>
> By checking that dloc->type_offset > result->self.size, the offset adjustment
> is skipped if the flexible array element being accessed has an offset less
> than or equal to the total padded size of the parent struct.
>
> The unadjusted offset fails to match children in fill_member_name(),
> erroneously falling back to the last member during offline perf data analysis.
As I said in the previous version, I think it's ok and it'll find the
member when the offset is less than the total size.
Thanks,
Namhyung
>
> > + struct annotated_member *flex_array = get_flex_array_member(result);
> > +
> > + if (flex_array && flex_array->size > 0) {
> > + int offset = dloc->type_offset;
> > +
> > + /* adjust offset in the flex array */
> > + offset -= flex_array->offset;
> > + offset %= flex_array->size;
> > + offset += flex_array->offset;
> > +
> > + dloc->type_offset = offset;
> > + }
> > + }
> > + return result;
> > }
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260915064035.1970175-1-namhyung@kernel.org?part=3
prev parent reply other threads:[~2026-09-16 5:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-15 6:40 [PATCH v3 0/3] perf annotate-data: Support flexible array types Namhyung Kim
2026-09-15 6:40 ` [PATCH v3 1/3] perf dwarf-aux: Add die_has_flex_array() helper Namhyung Kim
2026-09-15 6:50 ` sashiko-bot
2026-09-16 5:49 ` Namhyung Kim
2026-09-16 13:54 ` Masami Hiramatsu
2026-09-15 6:40 ` [PATCH v3 2/3] perf annotate-date: Allow out-of-size access for flex-array types Namhyung Kim
2026-09-15 6:48 ` sashiko-bot
2026-09-15 6:40 ` [PATCH v3 3/3] perf annotate-data: Adjust type offset for flex-array Namhyung Kim
2026-09-15 6:53 ` sashiko-bot
2026-09-16 5:58 ` Namhyung Kim [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=aqov9bkuxh6cNI5F@google.com \
--to=namhyung@kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--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