From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: David Laight <david.laight.linux@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
James Clark <james.clark@linaro.org>,
Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Kan Liang <kan.liang@linux.intel.com>,
Clark Williams <williams@redhat.com>,
linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: Re: [PATCH 3/4] perf list: Don't write to const memory
Date: Wed, 21 Jan 2026 22:10:18 -0300 [thread overview]
Message-ID: <aXF4-vLA9DvhsPdc@x1> (raw)
In-Reply-To: <20260121221713.1e7e0cf9@pumpkin>
On Wed, Jan 21, 2026 at 10:17:13PM +0000, David Laight wrote:
> On Tue, 20 Jan 2026 19:08:59 -0300
> Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> > From: Arnaldo Carvalho de Melo <acme@redhat.com>
> >
> > Something now detected on fedora 44, where strchr() returns const if it
> > is passed a const pointer:
> >
> > util/print-events.c: In function 'print_sdt_events':
> > util/print-events.c:89:29: error: initialization discards 'const' qualifier from pointer target type [-Werror=discarded-qualifiers]
> > 89 | char *bid = strchr(sdt_name->s, '@');
> > | ^~~~~~
> >
> > Fix it by using strnchr() if strchr finds the separator instead of
> > temporarily scrubbing it with '\0'.
>
> I've just looked at the full function to see WTF it is doing.
> You've fixed the second strchr() not the one the compiler bleated about.
It complained about both, no?
> Line 89 is followed by:
> if (bid)
> *bid++ = 0;
> but if it is NULL there is a fair chance the code will just explode a bit later on.
Why, can you elaborate?
> I suspect it is an error if the strings aren't "name@bar"
> 'show_detail' seems to be set if either the previous or next entries in the
> list/tree have the same "name" - which seems strange to me.
All this is strange, a corner case, it looks as if we may have multiple
binaries, differentiated by buildids, that would have different SDTs.
The code seems to be trying to reduce the amount of info (not showing
the buildid if there are no more at that point multiple versions of a
DSO with SDTs in place).
Further analysis of the changesets that put all this in place is needed
to clarify, but looking just at fixing what the compiler is complaining,
do you think the patches are bad?
- Arnaldo
> The while thing needs more work :-(
>
> David
>
> >
> > Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
> > ---
> > tools/perf/util/print-events.c | 13 +++++--------
> > 1 file changed, 5 insertions(+), 8 deletions(-)
> >
> > diff --git a/tools/perf/util/print-events.c b/tools/perf/util/print-events.c
> > index 8f3ed83853a9e468..898cf426509790cd 100644
> > --- a/tools/perf/util/print-events.c
> > +++ b/tools/perf/util/print-events.c
> > @@ -97,14 +97,11 @@ void print_sdt_events(const struct print_callbacks *print_cb, void *print_state)
> > } else {
> > next_sdt_name = strlist__next(sdt_name);
> > if (next_sdt_name) {
> > - char *bid2 = strchr(next_sdt_name->s, '@');
> > -
> > - if (bid2)
> > - *bid2 = '\0';
> > - if (strcmp(sdt_name->s, next_sdt_name->s) == 0)
> > - show_detail = true;
> > - if (bid2)
> > - *bid2 = '@';
> > + const char *bid2 = strchr(next_sdt_name->s, '@');
> > +
> > + show_detail = bid2 ?
> > + strncmp(sdt_name->s, next_sdt_name->s, bid2 - next_sdt_name->s) == 0 :
> > + strcmp(sdt_name->s, next_sdt_name->s) == 0;
> > }
> > }
> > last_sdt_name = sdt_name->s;
next prev parent reply other threads:[~2026-01-22 1:10 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-20 22:08 [PATCH 0/4] Fixes for gcc 16.0.1 Arnaldo Carvalho de Melo
2026-01-20 22:08 ` [PATCH 1/4] perf tests sw-clock: Mark the volatile tmp variable as __maybe_unused Arnaldo Carvalho de Melo
2026-01-20 22:08 ` [PATCH 2/4] perf trace: Deal with compiler const checks Arnaldo Carvalho de Melo
2026-01-20 22:08 ` [PATCH 3/4] perf list: Don't write to const memory Arnaldo Carvalho de Melo
2026-01-21 11:25 ` David Laight
2026-01-21 18:40 ` Arnaldo Carvalho de Melo
2026-01-21 18:44 ` Ian Rogers
2026-01-21 22:17 ` David Laight
2026-01-22 1:10 ` Arnaldo Carvalho de Melo [this message]
2026-01-22 9:55 ` David Laight
2026-01-20 22:09 ` [PATCH 4/4] perf list: Signal changing const memory is ok Arnaldo Carvalho de Melo
2026-01-20 23:42 ` [PATCH 0/4] Fixes for gcc 16.0.1 Ian Rogers
2026-01-20 23:50 ` Arnaldo Carvalho de Melo
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=aXF4-vLA9DvhsPdc@x1 \
--to=acme@kernel.org \
--cc=acme@redhat.com \
--cc=adrian.hunter@intel.com \
--cc=david.laight.linux@gmail.com \
--cc=irogers@google.com \
--cc=james.clark@linaro.org \
--cc=jolsa@kernel.org \
--cc=kan.liang@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=tglx@linutronix.de \
--cc=williams@redhat.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