Re: [PATCH] rcu-tasks: Update show_rcu_tasks_trace_gp_kthread buffer size

[Steven Rostedt]

On Tue, 26 Mar 2024 22:55:29 +0300
Nikita Kiryushin <kiryushin@xxxxxxxx> 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