[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9770045bcf400920152f0698c07090a641cc4aa1.camel@redhat.com>
Date: Mon, 24 Nov 2025 18:46:29 -0600
From: Crystal Wood <crwood@...hat.com>
To: Wander Lairson Costa <wander@...hat.com>, Steven Rostedt
<rostedt@...dmis.org>, Tomas Glozar <tglozar@...hat.com>, Ivan Pravdin
<ipravdin.official@...il.com>, John Kacur <jkacur@...hat.com>, Costa
Shulyupin <costa.shul@...hat.com>, Tiezhu Yang <yangtiezhu@...ngson.cn>,
"open list:Real-time Linux Analysis (RTLA) tools"
<linux-trace-kernel@...r.kernel.org>, open list
<linux-kernel@...r.kernel.org>, "open list:BPF
[MISC]:Keyword:(?:\\b|_)bpf(?:\\b|_)" <bpf@...r.kernel.org>
Subject: Re: [rtla 04/13] rtla: Replace atoi() with a robust strtoi()
On Mon, 2025-11-17 at 15:41 -0300, Wander Lairson Costa wrote:
>
> diff --git a/tools/tracing/rtla/src/actions.c b/tools/tracing/rtla/src/actions.c
> index efa17290926da..e23d4f1c5a592 100644
> --- a/tools/tracing/rtla/src/actions.c
> +++ b/tools/tracing/rtla/src/actions.c
> @@ -199,12 +199,14 @@ actions_parse(struct actions *self, const char *trigger, const char *tracefn)
> /* Takes two arguments, num (signal) and pid */
> while (token != NULL) {
> if (strlen(token) > 4 && strncmp(token, "num=", 4) == 0) {
> - signal = atoi(token + 4);
> + if(!strtoi(token + 4, &signal))
> + return -1;
if (
> } else if (strlen(token) > 4 && strncmp(token, "pid=", 4) == 0) {
> if (strncmp(token + 4, "parent", 7) == 0)
> pid = -1;
> else
> - pid = atoi(token + 4);
> + if (!strtoi(token + 4, &pid))
> + return -1;
else if (
Please run the patches through checkpatch.pl
> @@ -959,3 +967,25 @@ int auto_house_keeping(cpu_set_t *monitored_cpus)
>
> return 1;
> }
> +
> +/*
> + * strtoi - convert string to integer with error checking
> + *
> + * Returns true on success, false if conversion fails or result is out of int range.
> + */
> +bool strtoi(const char *s, int *res)
Could use __attribute__((__warn_unused_result__)) like kstrtoint().
BTW, it's pretty annoying that we need to reinvent the wheel on all this
stuff just because it's userspace. From some of the other tools it
looks like we can at least include basic kernel headers like compiler.h;
maybe we should have a tools/-wide common util area as well? Even
better if some of the code can be shared with the kernel itself.
Not saying that should in any way be a blocker for these patches, just
something to think about.
-Crystal
Powered by blists - more mailing lists