[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4b3e239d-ab87-4a37-ac1d-af49e1f8f3ee@ancud.ru>
Date: Tue, 26 Mar 2024 22:55:29 +0300
From: Nikita Kiryushin <kiryushin@...ud.ru>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: "Paul E. McKenney" <paulmck@...nel.org>,
Frederic Weisbecker <frederic@...nel.org>,
Neeraj Upadhyay <quic_neeraju@...cinc.com>,
Joel Fernandes <joel@...lfernandes.org>,
Josh Triplett <josh@...htriplett.org>, Boqun Feng <boqun.feng@...il.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Lai Jiangshan <jiangshanlai@...il.com>, Zqiang <qiang.zhang1211@...il.com>,
rcu@...r.kernel.org, linux-kernel@...r.kernel.org,
lvc-project@...uxtesting.org
Subject: Re: [PATCH] rcu-tasks: Update show_rcu_tasks_trace_gp_kthread buffer
size
On 3/26/24 22:22, Steven Rostedt wrote:
> Why 87? as it's not even word size, and this is on the stack.
>
Got 87 as maximal used buffer length (result of
sprintf(buf, "N%lu h:%lu/%lu/%lu",
(unsigned long int) -1,
(unsigned long int) -1,
(unsigned long int) -1,
(unsigned long int) -1);
+1 for terminator.
Is word-size alignment a thing in this case? I thought that char buffers
are ok to be aligned by 1?
> Better yet, why not just use snprintf()?
>
Seems like a better idea indeed, as if fixes overflows for unpractical cases,
without added overhead to common cases. The only concern is possible truncation
of data, that may break some automation (if output is parsed by someone,
without accounting on it being cut, who knows). But again, it is for pretty unpractical
values.
Will make a v2 patch with snprintf() with buffer length.
Genuinely look forward to being educated about aspects of aligning array sizes, as
I do not really understand the limitations.
Thanks!
Powered by blists - more mailing lists