From: Alejandro Colomar <alx@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: devicetree@vger.kernel.org, linux-gpio@vger.kernel.org,
robh@kernel.org, conor+dt@kernel.org,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH v5 7/7] string: Implement strstarts() with strprefix()
Date: Fri, 13 Nov 2026 14:36:36 +0100 [thread overview]
Message-ID: <avcR0tSX-Fcq9pPf@devuan> (raw)
In-Reply-To: <sashiko-outbox-212840@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4131 bytes --]
> Date: 2026-11-13 13:20:16+0000
> From: sashiko-bot@kernel.org
>
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue to consider:
> - [Low] string: strstarts() via strprefix() prevents optimizing out
> pointer offset
> --
>
> commit 8cdc2e9c96584305ea94313f2618d17d8e28f303
> Author: Alejandro Colomar <alx@kernel.org>
>
> string: Implement strstarts() with strprefix()
>
> This commit changes strstarts() to call strprefix() instead of calling
> strncmp() and strlen() directly.
>
> > diff --git a/include/linux/string.h b/include/linux/string.h
> > index 8c6a79d320474..8ca0deda61606 100644
> > --- a/include/linux/string.h
> > +++ b/include/linux/string.h
> > @@ -595,7 +595,7 @@ static inline const char *strprefix(const char *s, const char *prefix)
> > */
> > static inline bool strstarts(const char *str, const char *prefix)
> > {
> > - return strncmp(str, prefix, strlen(prefix)) == 0;
> > + return strprefix(str, prefix);
> > }
>
> [Severity: Low]
> Can the compiler actually optimize away the s + len pointer arithmetic in
> strprefix() here?
>
> strprefix() returns strncmp(s, prefix, len) == 0 ? s + len : NULL, and
> converting that result to bool requires proving that s + len is non-NULL
> whenever strncmp() returns 0. Because the kernel builds with
> -fno-delete-null-pointer-checks and -fno-strict-overflow, the compiler
> cannot assume that a runtime pointer is non-NULL or that s + len does not
> wrap to NULL, so callers of strstarts() end up keeping str and len live
> across strncmp() and emitting the extra addition and NULL check.
Hmmm, it seems it's right; the compiler can't optimize out. I hadn't
taken those flags into account.
Here's a test which seems to corroborate:
alx@devuan:~/tmp$ cat strstarts.c
#include <string.h>
bool strstarts(const char *s, const char *prefix)
{
return strncmp(s, prefix, strlen(prefix)) == 0;
}
alx@devuan:~/tmp$ cat strprefix.c
#include <string.h>
bool strstarts(const char *s, const char *prefix)
{
size_t len = strlen(prefix);
return strncmp(s, prefix, len) == 0 ? s + len : NULL;
}
alx@devuan:~/tmp$ gcc -Wall -Wextra -O2 -fno-delete-null-pointer-checks -fno-strict-overflow -S strstarts.c
alx@devuan:~/tmp$ gcc -Wall -Wextra -O2 -fno-delete-null-pointer-checks -fno-strict-overflow -S strprefix.c
strprefix.c: In function ‘strstarts’:
strprefix.c:5:9: warning: the comparison will always evaluate as ‘true’ for the pointer operand in ‘s + (sizetype)len’ must not be NULL [-Waddress]
5 | return strncmp(s, prefix, len) == 0 ? s + len : NULL;
| ^~~~~~
alx@devuan:~/tmp$ diff -u strstarts.s strprefix.s
--- strstarts.s 2026-11-13 14:33:48.478848453 +0100
+++ strprefix.s 2026-11-13 14:33:51.802880696 +0100
@@ -1,4 +1,4 @@
- .file "strstarts.c"
+ .file "strprefix.c"
.text
.p2align 4
.globl strstarts
@@ -6,24 +6,45 @@
strstarts:
.LFB0:
.cfi_startproc
- pushq %rbx
+ pushq %rbp
.cfi_def_cfa_offset 16
- .cfi_offset 3, -16
+ .cfi_offset 6, -16
+ pushq %rbx
+ .cfi_def_cfa_offset 24
+ .cfi_offset 3, -24
movq %rdi, %rbx
movq %rsi, %rdi
- subq $16, %rsp
- .cfi_def_cfa_offset 32
+ subq $24, %rsp
+ .cfi_def_cfa_offset 48
movq %rsi, 8(%rsp)
call strlen@PLT
movq 8(%rsp), %rsi
movq %rbx, %rdi
movq %rax, %rdx
+ movq %rax, %rbp
call strncmp@PLT
testl %eax, %eax
- sete %al
- addq $16, %rsp
+ jne .L4
+ addq %rbp, %rbx
+ setne %al
+ addq $24, %rsp
+ .cfi_remember_state
+ .cfi_def_cfa_offset 24
+ popq %rbx
.cfi_def_cfa_offset 16
+ popq %rbp
+ .cfi_def_cfa_offset 8
+ ret
+ .p2align 4,,10
+ .p2align 3
+.L4:
+ .cfi_restore_state
+ addq $24, %rsp
+ .cfi_def_cfa_offset 24
+ xorl %eax, %eax
popq %rbx
+ .cfi_def_cfa_offset 16
+ popq %rbp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
I'll drop patch 7/7 in v6.
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/cover.1794574496.git.alx@kernel.org?part=7
--
<https://www.alejandro-colomar.es>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2026-11-13 13:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-13 13:10 [PATCH v5 0/7] Add strprefix() and fix a bug with it Alejandro Colomar
2026-11-13 13:10 ` [PATCH v5 1/7] string: Add strprefix(), and deprecate str_has_prefix() Alejandro Colomar
2026-11-13 13:10 ` [PATCH v5 2/7] string: Warn if the prefix is the empty string Alejandro Colomar
2026-11-13 13:26 ` sashiko-bot
2026-11-13 13:48 ` Alejandro Colomar
2026-11-13 13:10 ` [PATCH v5 3/7] device property: Fix fwnode_name_eq() for empty node names Alejandro Colomar
2026-11-13 13:10 ` [PATCH v5 4/7] stddef: Add const_cast() Alejandro Colomar
2026-11-13 13:11 ` [PATCH v5 5/7] string: Add [C]QChar_of() and QVoid_of() Alejandro Colomar
2026-11-13 13:11 ` [PATCH v5 6/7] string: Make strprefix() const-qualifier-generic Alejandro Colomar
2026-11-13 13:11 ` [PATCH v5 7/7] string: Implement strstarts() with strprefix() Alejandro Colomar
2026-11-13 13:20 ` sashiko-bot
2026-11-13 13:36 ` Alejandro Colomar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=avcR0tSX-Fcq9pPf@devuan \
--to=alx@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-gpio@vger.kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=robh@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox