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
