Re: [PATCH v1 1/1] ACPI: processor: idle: Replace strlcat() with better alternative

[Andy Shevchenko <andriy.shevchenko@linux.intel.com>]

On Fri, Mar 20, 2026 at 12:34:42PM -0700, Kees Cook wrote:
> On Fri, Mar 20, 2026 at 09:25:41PM +0200, Andy Shevchenko wrote:
> > On Fri, Mar 20, 2026 at 12:17:54PM -0700, Kees Cook wrote:
> > > On Mon, Mar 16, 2026 at 06:01:58PM +0100, Andy Shevchenko wrote:
> > > > strlcpy() and strlcat() are confusing APIs and the former one already gone
> > > > from the kernel. In preparation to kill strlcat() replace it with the better
> > > > alternative.
> > > 
> > > Yes please. There are a few places I looked at in the past that might
> > > benefit from being changed to seq_buf or similar (where snprintf doesn't
> > > cut it), but otherwise the removal of strlcat should be straight forward
> > > and would be well appreciated. :)
> > 
> > Thank you for confirming, this is basically the message to Josh to find
> > users and start converting them and kill strlcat() eventually. Josh, as
> > you see it will be well appreciated!
> 
> As an example of a seq_buf user, see block/partitions/core.c:
> 
> static struct parsed_partitions *check_partition(struct gendisk *hd)
> {
> 	...
>         state->pp_buf = (char *)__get_free_page(GFP_KERNEL);
> 	...
>         state->pp_buf[0] = '\0';
> 	...
>         snprintf(state->pp_buf, PAGE_SIZE, " %s:", state->name);
> 	...
>         while (!res && check_part[i]) {
> 		...
>                 res = check_part[i++](state);
> ...
> 
> All the partition handlers then use strlcat to append more details,
> and it's totally unbounded. The correct thing would be to build a
> seq_buf to attach to state instead of the pp_buf, and the handlers would
> use seq_buf functions to append their info, etc etc.

Indeed. Thanks for sharing the ideas!

-- 
With Best Regards,
Andy Shevchenko