Received-SPF: pass (google.com: domain of linux-kernel+bounces-119908-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Date: Tue, 26 Mar 2024 16:28:38 -0400
From: Steven Rostedt <rostedt@goodmis.org>
To: Nikita Kiryushin <kiryushin@ancud.ru>
Cc: "Paul E. McKenney" <paulmck@kernel.org>, Frederic Weisbecker
 <frederic@kernel.org>, Neeraj Upadhyay <quic_neeraju@quicinc.com>, Joel
 Fernandes <joel@joelfernandes.org>, Josh Triplett <josh@joshtriplett.org>,
 Boqun Feng <boqun.feng@gmail.com>, Mathieu Desnoyers
 <mathieu.desnoyers@efficios.com>, Lai Jiangshan <jiangshanlai@gmail.com>,
 Zqiang <qiang.zhang1211@gmail.com>, rcu@vger.kernel.org,
 linux-kernel@vger.kernel.org, lvc-project@linuxtesting.org
Subject: Re: [PATCH] rcu-tasks: Update show_rcu_tasks_trace_gp_kthread
 buffer size
Message-ID: <20240326162838.14da4a7c@gandalf.local.home>
In-Reply-To: <4b3e239d-ab87-4a37-ac1d-af49e1f8f3ee@ancud.ru>
References: <20240326174839.487582-1-kiryushin@ancud.ru>
	<20240326152230.3e692d83@gandalf.local.home>
	<4b3e239d-ab87-4a37-ac1d-af49e1f8f3ee@ancud.ru>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, 26 Mar 2024 22:55:29 +0300
Nikita Kiryushin <kiryushin@ancud.ru> wrote:

> On 3/26/24 22:22, Steven Rostedt wrote:
> > Why 87? as it's not even word size, and this is on the stack.
> > =20
> Got 87 as maximal used buffer length (result of
> sprintf(buf, "N%lu h:%lu/%lu/%lu",
>  =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 (unsigned long int) -1,
>  =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 (unsigned long int) -1,
>  =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 (unsigned long int) -1,
>  =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0 (unsigned long int) -1);
> +1 for terminator.
>=20
> Is word-size alignment a thing in this case? I thought that char buffers
> are ok to be aligned by 1?

Because it's on the stack, which will likely reserve data in word size.

Thus, buf[87] reserves as much data on the stack as buf[88].


> > Better yet, why not just use snprintf()?
> > =20
> Seems like a better idea indeed, as if fixes overflows for unpractical ca=
ses,
> without added overhead to common cases. The only concern is possible trun=
cation
> 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 pret=
ty unpractical
> values.
>=20
> Will make a v2 patch with snprintf() with buffer length.
>=20
> Genuinely look forward to being educated about aspects of aligning array =
sizes, as
> I do not really understand the limitations.

It's because it's on the stack, but it's always good to align. For
instance, kmalloc() will allocate things in 32 byte chunks.

-- Steve