linux-kernel - Re: [PATCH] rcu-tasks: Update show_rcu_tasks_trace_gp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240326162838.14da4a7c@gandalf.local.home>
Date: Tue, 26 Mar 2024 16:28:38 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Nikita Kiryushin <kiryushin@...ud.ru>
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 Tue, 26 Mar 2024 22:55:29 +0300
Nikita Kiryushin <kiryushin@...ud.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.
> >  
> 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?

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()?
> >  
> 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.

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