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

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

[Andy Shevchenko]

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.

Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
 drivers/acpi/processor_idle.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
index 45b5d17443cf..498d88f5d5c9 100644
--- a/drivers/acpi/processor_idle.c
+++ b/drivers/acpi/processor_idle.c
@@ -1010,9 +1010,7 @@ static bool combine_lpi_states(struct acpi_lpi_state *local,
 	result->arch_flags = parent->arch_flags;
 	result->index = parent->index;
 
-	strscpy(result->desc, local->desc, ACPI_CX_DESC_LEN);
-	strlcat(result->desc, "+", ACPI_CX_DESC_LEN);
-	strlcat(result->desc, parent->desc, ACPI_CX_DESC_LEN);
+	snprintf(result->desc, ACPI_CX_DESC_LEN, "%s+%s", local->desc, parent->desc);
 	return true;
 }
 
-- 
2.50.1

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

[Josh Law]

On 16 March 2026 17:01:58 GMT, Andy Shevchenko <andriy.shevchenko@linux.intel.com> 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.
>
>Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
>---
> drivers/acpi/processor_idle.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
>diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
>index 45b5d17443cf..498d88f5d5c9 100644
>--- a/drivers/acpi/processor_idle.c
>+++ b/drivers/acpi/processor_idle.c
>@@ -1010,9 +1010,7 @@ static bool combine_lpi_states(struct acpi_lpi_state *local,
> 	result->arch_flags = parent->arch_flags;
> 	result->index = parent->index;
> 
>-	strscpy(result->desc, local->desc, ACPI_CX_DESC_LEN);
>-	strlcat(result->desc, "+", ACPI_CX_DESC_LEN);
>-	strlcat(result->desc, parent->desc, ACPI_CX_DESC_LEN);
>+	snprintf(result->desc, ACPI_CX_DESC_LEN, "%s+%s", local->desc, parent->desc);
> 	return true;
> }
> 


Is this patch in relation to my string.c patch? You would have to do this for about 120~ files.

V/R


Josh Law

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

[Andy Shevchenko]

On Mon, Mar 16, 2026 at 06:43:58PM +0000, Josh Law wrote:
> On 16 March 2026 17:01:58 GMT, Andy Shevchenko <andriy.shevchenko@linux.intel.com> 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.
> 
> Is this patch in relation to my string.c patch?

Yes.

> You would have to do this for about 120~ files.

Not me, just showing you what to do.

Btw, what kind of assistance do you use for the patches?


-- 
With Best Regards,
Andy Shevchenko

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

[Josh Law]

On 16 March 2026 18:47:45 GMT, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>On Mon, Mar 16, 2026 at 06:43:58PM +0000, Josh Law wrote:
>> On 16 March 2026 17:01:58 GMT, Andy Shevchenko <andriy.shevchenko@linux.intel.com> 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.
>> 
>> Is this patch in relation to my string.c patch?
>
>Yes.
>
>> You would have to do this for about 120~ files.
>
>Not me, just showing you what to do.
>
>Btw, what kind of assistance do you use for the patches?
>
>



None

I use grep to find all the files calling the functions (took a while!)


And if I did those patches, I can't guarantee all of them will be ACKed.

V/R


Josh Law

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

[Andy Shevchenko]

On Mon, Mar 16, 2026 at 06:49:23PM +0000, Josh Law wrote:
> On 16 March 2026 18:47:45 GMT, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
> >On Mon, Mar 16, 2026 at 06:43:58PM +0000, Josh Law wrote:
> >> On 16 March 2026 17:01:58 GMT, Andy Shevchenko <andriy.shevchenko@linux.intel.com> 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.
> >> 
> >> Is this patch in relation to my string.c patch?
> >
> >Yes.
> >
> >> You would have to do this for about 120~ files.
> >
> >Not me, just showing you what to do.
> >
> >Btw, what kind of assistance do you use for the patches?
> 
> None

Hmm... Many patches that are generated require quite a lot of time investment
and understanding the code. It's unbelievable that a person can do that without
an assistance.

> I use grep to find all the files calling the functions (took a while!)

No, that's not what I was asking about.

> And if I did those patches, I can't guarantee all of them will be ACKed.

Interesting way of saying the obvious. And if you didn't?..

-- 
With Best Regards,
Andy Shevchenko

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

[Josh Law]

On 16 March 2026 19:42:49 GMT, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>On Mon, Mar 16, 2026 at 06:49:23PM +0000, Josh Law wrote:
>> On 16 March 2026 18:47:45 GMT, Andy Shevchenko <andriy.shevchenko@linux.intel.com> wrote:
>> >On Mon, Mar 16, 2026 at 06:43:58PM +0000, Josh Law wrote:
>> >> On 16 March 2026 17:01:58 GMT, Andy Shevchenko <andriy.shevchenko@linux.intel.com> 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.
>> >> 
>> >> Is this patch in relation to my string.c patch?
>> >
>> >Yes.
>> >
>> >> You would have to do this for about 120~ files.
>> >
>> >Not me, just showing you what to do.
>> >
>> >Btw, what kind of assistance do you use for the patches?
>> 
>> None
>
>Hmm... Many patches that are generated require quite a lot of time investment
>and understanding the code. It's unbelievable that a person can do that without
>an assistance.
>
>> I use grep to find all the files calling the functions (took a while!)
>
>No, that's not what I was asking about.
>
>> And if I did those patches, I can't guarantee all of them will be ACKed.
>
>Interesting way of saying the obvious. And if you didn't?..
>


I understand your suspicion, my commit descriptions are written by a LLM, but the actual code itself is mine, the reason why I do commit descriptions with AI, is because I'm not the "sharpest tool in the shed" with writing descriptions for anything! If I add a feature, I can't do much writing about it, and I worry that if I can't explain a feature well, it won't get merged. I'm sorry for all the confusion, also. The reason I do high volume of patches is quite simple.

I love lib/ basically, it's my favourite directory to work on, For various reasons, and I have quite high work energy for my "passions", sorry if you think I use assistance for everything (I don't, only for commit descriptions), I will slow down from now on with the patches.

And from now on I will try to manually write descriptions (even though I'm not the best at writing anything, even if I understand it heavily)
 

V/R


Josh Law

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

[kernel test robot]

Hi Andy,

kernel test robot noticed the following build warnings:

[auto build test WARNING on rafael-pm/linux-next]
[also build test WARNING on rafael-pm/bleeding-edge linus/master v7.0-rc4 next-20260316]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]

url:    https://github.com/intel-lab-lkp/linux/commits/Andy-Shevchenko/ACPI-processor-idle-Replace-strlcat-with-better-alternative/20260317-014800
base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
patch link:    https://lore.kernel.org/r/20260316170158.1596857-1-andriy.shevchenko%40linux.intel.com
patch subject: [PATCH v1 1/1] ACPI: processor: idle: Replace strlcat() with better alternative
config: x86_64-rhel-9.4 (https://download.01.org/0day-ci/archive/20260317/202603170957.D9ZQ5sVR-lkp@intel.com/config)
compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260317/202603170957.D9ZQ5sVR-lkp@intel.com/reproduce)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202603170957.D9ZQ5sVR-lkp@intel.com/

All warnings (new ones prefixed by >>):

   drivers/acpi/processor_idle.c: In function 'flatten_lpi_states':
>> drivers/acpi/processor_idle.c:1013:56: warning: 'snprintf' output may be truncated before the last format character [-Wformat-truncation=]
    1013 |         snprintf(result->desc, ACPI_CX_DESC_LEN, "%s+%s", local->desc, parent->desc);
         |                                                        ^
   In function 'combine_lpi_states',
       inlined from 'flatten_lpi_states' at drivers/acpi/processor_idle.c:1059:8:
   drivers/acpi/processor_idle.c:1013:9: note: 'snprintf' output 2 or more bytes (assuming 33) into a destination of size 32
    1013 |         snprintf(result->desc, ACPI_CX_DESC_LEN, "%s+%s", local->desc, parent->desc);
         |         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~


vim +/snprintf +1013 drivers/acpi/processor_idle.c

   984	
   985	/**
   986	 * combine_lpi_states - combine local and parent LPI states to form a composite LPI state
   987	 *
   988	 * @local: local LPI state
   989	 * @parent: parent LPI state
   990	 * @result: composite LPI state
   991	 */
   992	static bool combine_lpi_states(struct acpi_lpi_state *local,
   993				       struct acpi_lpi_state *parent,
   994				       struct acpi_lpi_state *result)
   995	{
   996		if (parent->entry_method == ACPI_CSTATE_INTEGER) {
   997			if (!parent->address) /* 0 means autopromotable */
   998				return false;
   999			result->address = local->address + parent->address;
  1000		} else {
  1001			result->address = parent->address;
  1002		}
  1003	
  1004		result->min_residency = max(local->min_residency, parent->min_residency);
  1005		result->wake_latency = local->wake_latency + parent->wake_latency;
  1006		result->enable_parent_state = parent->enable_parent_state;
  1007		result->entry_method = local->entry_method;
  1008	
  1009		result->flags = parent->flags;
  1010		result->arch_flags = parent->arch_flags;
  1011		result->index = parent->index;
  1012	
> 1013		snprintf(result->desc, ACPI_CX_DESC_LEN, "%s+%s", local->desc, parent->desc);
  1014		return true;
  1015	}
  1016	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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

[Andy Shevchenko]

On Tue, Mar 17, 2026 at 09:17:56AM +0100, kernel test robot wrote:
> Hi Andy,
> 
> kernel test robot noticed the following build warnings:
> 
> [auto build test WARNING on rafael-pm/linux-next]
> [also build test WARNING on rafael-pm/bleeding-edge linus/master v7.0-rc4 next-20260316]
> [If your patch is applied to the wrong git tree, kindly drop us a note.
> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch#_base_tree_information]
> 
> url:    https://github.com/intel-lab-lkp/linux/commits/Andy-Shevchenko/ACPI-processor-idle-Replace-strlcat-with-better-alternative/20260317-014800
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git linux-next
> patch link:    https://lore.kernel.org/r/20260316170158.1596857-1-andriy.shevchenko%40linux.intel.com
> patch subject: [PATCH v1 1/1] ACPI: processor: idle: Replace strlcat() with better alternative
> config: x86_64-rhel-9.4 (https://download.01.org/0day-ci/archive/20260317/202603170957.D9ZQ5sVR-lkp@intel.com/config)
> compiler: gcc-14 (Debian 14.2.0-19) 14.2.0
> reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260317/202603170957.D9ZQ5sVR-lkp@intel.com/reproduce)
> 
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <lkp@intel.com>
> | Closes: https://lore.kernel.org/oe-kbuild-all/202603170957.D9ZQ5sVR-lkp@intel.com/

Yes, thanks, I already sent a v2 before getting this report.

-- 
With Best Regards,
Andy Shevchenko

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

[Kees Cook]

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. :)

> 
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>

Reviewed-by: Kees Cook <kees@kernel.org>

-Kees

> ---
>  drivers/acpi/processor_idle.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/acpi/processor_idle.c b/drivers/acpi/processor_idle.c
> index 45b5d17443cf..498d88f5d5c9 100644
> --- a/drivers/acpi/processor_idle.c
> +++ b/drivers/acpi/processor_idle.c
> @@ -1010,9 +1010,7 @@ static bool combine_lpi_states(struct acpi_lpi_state *local,
>  	result->arch_flags = parent->arch_flags;
>  	result->index = parent->index;
>  
> -	strscpy(result->desc, local->desc, ACPI_CX_DESC_LEN);
> -	strlcat(result->desc, "+", ACPI_CX_DESC_LEN);
> -	strlcat(result->desc, parent->desc, ACPI_CX_DESC_LEN);
> +	snprintf(result->desc, ACPI_CX_DESC_LEN, "%s+%s", local->desc, parent->desc);
>  	return true;
>  }
>  
> -- 
> 2.50.1
> 

-- 
Kees Cook

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

[Andy Shevchenko]

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!

> > Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> 
> Reviewed-by: Kees Cook <kees@kernel.org>

Thanks! There was a v2 which Rafael already accepted where scnprintf() is used
due to GCC complains about snprintf() potential string cuts.

-- 
With Best Regards,
Andy Shevchenko

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

[Kees Cook]

On Fri, Mar 20, 2026 at 09:25:41PM +0200, Andy Shevchenko wrote:
> Thanks! There was a v2 which Rafael already accepted where scnprintf() is used
> due to GCC complains about snprintf() potential string cuts.

Oops, yes, I see that now. Looks good!

-- 
Kees Cook

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

[Josh Law]

>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!


Thank you! But the only reason I'm not doing it is because if I submit all of the patches, let's say, 50 gets merged (including strings.c) and like 50 don't, then 50 will have a nonexistent/slow API because they chose to not merge my patch

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

[Andy Shevchenko]

On Fri, Mar 20, 2026 at 07:31:54PM +0000, Josh Law wrote:
> 
> 
> >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!
> 
> Thank you! But the only reason I'm not doing it is because if I submit all of
> the patches, let's say, 50 gets merged (including strings.c) and like 50
> don't, then 50 will have a nonexistent/slow API because they chose to not
> merge my patch

Huh?! Even if you do 50%, it will still be appreciated as it's not a job that
has to be done in one cycle. Also we expect to have a constructive feedback
from the maintainers. Killing an old and confusing API is a good justification
and it will be rare maintainer even thinking to tell against. The feedback
may be given to the implementation and how to improve or adjust, but believe
close to 0 maintainers will say a word against dropping strlcat().

-- 
With Best Regards,
Andy Shevchenko

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

[Kees Cook]

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.

-Kees

-- 
Kees Cook

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

[Andy Shevchenko]

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