* Re: [PATCH 4/5] docs: fix repeated prepositions across documentation
From: Randy Dunlap @ 2026-05-09 20:41 UTC (permalink / raw)
To: Andrew Lunn
Cc: Shuah Khan, Adrien Reynard, Andrey Ryabinin, Alexander Potapenko,
Andrey Konovalov, Dmitry Vyukov, Vincenzo Frascino,
Jonathan Corbet, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Richard Weinberger, Anton Ivanov,
Johannes Berg, open list:KASAN, open list:DOCUMENTATION PROCESS,
open list:DOCUMENTATION, open list,
open list:NETWORKING [GENERAL], open list:USER-MODE LINUX (UML)
In-Reply-To: <3b4357a7-f70d-41b0-a75d-c30f9fb7dd98@lunn.ch>
On 5/9/26 12:39 PM, Andrew Lunn wrote:
>>> Can we get the tool changed to add a warning, something like:
>>>
>>> WARNING: This tool uses very simple pattern matching to look for
>>> repeated words. It does not understand the complexity of English,
>>> and will often result in false positive reports. Please assume it is
>>> wrong until proven otherwise.
>>
>> There was no commit log and no cover letter AFAIK.
>> Do we know what tool was used?
>>
>> Adrien, how did you discover these repeated words?
>>
>> (If it's my script from 2021, I'll gladly update it.)
Adrien is not using my script -- they developed their own script.
> Thinking about it some more, i think the warning might actually need
> to be different.
>
> If this tool has been around since 2021, all the real problems have
> been solved, leaving only the false positives. So the warning probably
> needs to be much stronger, saying that it probably only reports false
> positives, unless the code is new.
Makes some sense.
> Maybe we also want to extend the tool to have a list all the known
> false positives?
I'm not crazy about that one. And we have no evidence that I am aware
of that my script is causing any of these patches.
--
~Randy
^ permalink raw reply
* [PATCH 0/2] Doc, scripts: facilitate phaseout of strlcat
From: Manuel Ebner @ 2026-05-10 16:49 UTC (permalink / raw)
To: Andy Shevchenko, Kees Cook, Jonathan Corbet, Shuah Khan,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
open list:DOCUMENTATION PROCESS, open list:DOCUMENTATION,
open list
Cc: Manuel Ebner
The goal of this series is to facilitate the transition from strlcat to better
alternatives.
^ permalink raw reply
* [PATCH 1/2] [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: Manuel Ebner @ 2026-05-10 16:52 UTC (permalink / raw)
To: manuelebner
Cc: andy.shevchenko, apw, corbet, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <20260510164907.57176-2-manuelebner@mailbox.org>
add strlcat and alternatives
---
Documentation/process/deprecated.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
index fed56864d036..b8a65c19796c 100644
--- a/Documentation/process/deprecated.rst
+++ b/Documentation/process/deprecated.rst
@@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is strscpy(),
though care must be given to any cases where the return value of strlcpy()
is used, since strscpy() will return negative errno values when it truncates.
+strlcat()
+---------
+strlcat() must re-scan the destination string from the beginning on each
+call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
+snprintf() and scnprintf()
+
%p format specifier
-------------------
Traditionally, using "%p" in format strings would lead to regular address
--
2.54.0
^ permalink raw reply related
* [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: Manuel Ebner @ 2026-05-10 16:54 UTC (permalink / raw)
To: manuelebner
Cc: andy.shevchenko, apw, corbet, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <20260510164907.57176-2-manuelebner@mailbox.org>
add strlcat and alternatives
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
Documentation/process/deprecated.rst | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
index fed56864d036..b8a65c19796c 100644
--- a/Documentation/process/deprecated.rst
+++ b/Documentation/process/deprecated.rst
@@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is strscpy(),
though care must be given to any cases where the return value of strlcpy()
is used, since strscpy() will return negative errno values when it truncates.
+strlcat()
+---------
+strlcat() must re-scan the destination string from the beginning on each
+call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
+snprintf() and scnprintf()
+
%p format specifier
-------------------
Traditionally, using "%p" in format strings would lead to regular address
--
2.54.0
^ permalink raw reply related
* [PATCH 2/2] scripts: checkpatch.pl: add warning for strlcat()
From: Manuel Ebner @ 2026-05-10 16:56 UTC (permalink / raw)
To: manuelebner
Cc: andy.shevchenko, apw, corbet, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <20260510164907.57176-2-manuelebner@mailbox.org>
add a warning for strlcat()
Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
---
scripts/checkpatch.pl | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 0492d6afc9a1..ca1a8e67d529 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -7085,6 +7085,12 @@ sub process {
"Prefer strscpy over strlcpy - see: https://github.com/KSPP/linux/issues/89\n" . $herecurr);
}
+# strlcat uses that should likely be
+ if ($line =~ /\bstrlcat\s*\(/ && !is_userspace($realfile)) {
+ WARN("STRLCAT",
+ "Prefer seq_buf_printf() over strlcat - see: https://github.com/KSPP/linux/issues/370\n" . $herecurr);
+ }
+
# strncpy uses that should likely be strscpy or strscpy_pad
if ($line =~ /\bstrncpy\s*\(/ && !is_userspace($realfile)) {
WARN("STRNCPY",
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 2/2] scripts: checkpatch.pl: add warning for strlcat()
From: Randy Dunlap @ 2026-05-10 17:31 UTC (permalink / raw)
To: Manuel Ebner
Cc: andy.shevchenko, apw, corbet, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <20260510165649.57880-2-manuelebner@mailbox.org>
On 5/10/26 9:56 AM, Manuel Ebner wrote:
> add a warning for strlcat()
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> ---
> scripts/checkpatch.pl | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 0492d6afc9a1..ca1a8e67d529 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -7085,6 +7085,12 @@ sub process {
> "Prefer strscpy over strlcpy - see: https://github.com/KSPP/linux/issues/89\n" . $herecurr);
> }
>
> +# strlcat uses that should likely be
should likely be what?
> + if ($line =~ /\bstrlcat\s*\(/ && !is_userspace($realfile)) {
> + WARN("STRLCAT",
> + "Prefer seq_buf_printf() over strlcat - see: https://github.com/KSPP/linux/issues/370\n" . $herecurr);
> + }
> +
> # strncpy uses that should likely be strscpy or strscpy_pad
> if ($line =~ /\bstrncpy\s*\(/ && !is_userspace($realfile)) {
> WARN("STRNCPY",
--
~Randy
^ permalink raw reply
* Re: [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: Randy Dunlap @ 2026-05-10 17:32 UTC (permalink / raw)
To: Manuel Ebner
Cc: andy.shevchenko, apw, corbet, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <20260510165451.57674-2-manuelebner@mailbox.org>
On 5/10/26 9:54 AM, Manuel Ebner wrote:
> add strlcat and alternatives
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> ---
> Documentation/process/deprecated.rst | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
> index fed56864d036..b8a65c19796c 100644
> --- a/Documentation/process/deprecated.rst
> +++ b/Documentation/process/deprecated.rst
> @@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is strscpy(),
> though care must be given to any cases where the return value of strlcpy()
> is used, since strscpy() will return negative errno values when it truncates.
>
> +strlcat()
> +---------
> +strlcat() must re-scan the destination string from the beginning on each
> +call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
> +snprintf() and scnprintf()
Add an ending period.
> +
> %p format specifier
> -------------------
> Traditionally, using "%p" in format strings would lead to regular address
--
~Randy
^ permalink raw reply
* Re: [PATCH 1/2] [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: Geert Uytterhoeven @ 2026-05-11 11:40 UTC (permalink / raw)
To: Manuel Ebner
Cc: andy.shevchenko, apw, corbet, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <20260510165159.57457-2-manuelebner@mailbox.org>
Hi Manuel,
On Sun, 10 May 2026 at 18:52, Manuel Ebner <manuelebner@mailbox.org> wrote:
> add strlcat and alternatives
Thanks for your patch!
> --- a/Documentation/process/deprecated.rst
> +++ b/Documentation/process/deprecated.rst
> @@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is strscpy(),
> though care must be given to any cases where the return value of strlcpy()
> is used, since strscpy() will return negative errno values when it truncates.
>
> +strlcat()
> +---------
> +strlcat() must re-scan the destination string from the beginning on each
> +call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
> +snprintf() and scnprintf()
The last two not only require the caller to keep track of the offset
in the buffer, but also using "%s" when storing passed strings.
I hope we won't see mindless conversions lacking the "%s",
introducing new security issues:
-strlcat(buf, s, size);
+scnprintf(buf + off, size - off, s);
> +
> %p format specifier
> -------------------
> Traditionally, using "%p" in format strings would lead to regular address
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH 2/2] scripts: checkpatch.pl: add warning for strlcat()
From: Jonathan Corbet @ 2026-05-11 12:12 UTC (permalink / raw)
To: Manuel Ebner, manuelebner
Cc: andy.shevchenko, apw, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <20260510165649.57880-2-manuelebner@mailbox.org>
Manuel Ebner <manuelebner@mailbox.org> writes:
> add a warning for strlcat()
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> ---
> scripts/checkpatch.pl | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 0492d6afc9a1..ca1a8e67d529 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -7085,6 +7085,12 @@ sub process {
> "Prefer strscpy over strlcpy - see: https://github.com/KSPP/linux/issues/89\n" . $herecurr);
> }
>
> +# strlcat uses that should likely be
> + if ($line =~ /\bstrlcat\s*\(/ && !is_userspace($realfile)) {
> + WARN("STRLCAT",
> + "Prefer seq_buf_printf() over strlcat - see: https://github.com/KSPP/linux/issues/370\n" . $herecurr);
> + }
Using seq_buf_printf() requires switching over to the seq_buf API in
general, it is not just a simple substitution, so this advice may prove
unhelpful to many.
jon
^ permalink raw reply
* Re: [PATCH 1/2] [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: David Laight @ 2026-05-11 13:26 UTC (permalink / raw)
To: Geert Uytterhoeven
Cc: Manuel Ebner, andy.shevchenko, apw, corbet, dwaipayanray1, joe,
kees, linux-doc, linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <CAMuHMdWchXXcMyShiMZrhFTrHoB-TcKQEBcRoCTJFpwJsxxdhg@mail.gmail.com>
On Mon, 11 May 2026 13:40:55 +0200
Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> Hi Manuel,
>
> On Sun, 10 May 2026 at 18:52, Manuel Ebner <manuelebner@mailbox.org> wrote:
> > add strlcat and alternatives
>
> Thanks for your patch!
>
> > --- a/Documentation/process/deprecated.rst
> > +++ b/Documentation/process/deprecated.rst
> > @@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is strscpy(),
> > though care must be given to any cases where the return value of strlcpy()
> > is used, since strscpy() will return negative errno values when it truncates.
> >
> > +strlcat()
> > +---------
> > +strlcat() must re-scan the destination string from the beginning on each
> > +call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
> > +snprintf() and scnprintf()
>
> The last two not only require the caller to keep track of the offset
> in the buffer, but also using "%s" when storing passed strings.
Which also means they are significantly slower.
Mind you, some code has:
strlcat(buf, "\n", SIZE);
return strlen(buf);
which carefully scans the string twice.
Since the '\0' isn't always needed (eg 'show' functions), this can be:
len = strlen(buf);
buf[len] ='\n';
return len + 1;
Of course, the code could often easily get the length by other means.
-- David
>
> I hope we won't see mindless conversions lacking the "%s",
> introducing new security issues:
>
> -strlcat(buf, s, size);
> +scnprintf(buf + off, size - off, s);
>
> > +
> > %p format specifier
> > -------------------
> > Traditionally, using "%p" in format strings would lead to regular address
>
> Gr{oetje,eeting}s,
>
> Geert
>
^ permalink raw reply
* Re: [PATCH 2/2] scripts: checkpatch.pl: add warning for strlcat()
From: David Laight @ 2026-05-11 13:27 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Manuel Ebner, andy.shevchenko, apw, dwaipayanray1, joe, kees,
linux-doc, linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <87a4u6w3ez.fsf@trenco.lwn.net>
On Mon, 11 May 2026 06:12:36 -0600
Jonathan Corbet <corbet@lwn.net> wrote:
> Manuel Ebner <manuelebner@mailbox.org> writes:
>
> > add a warning for strlcat()
> >
> > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> > ---
> > scripts/checkpatch.pl | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 0492d6afc9a1..ca1a8e67d529 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -7085,6 +7085,12 @@ sub process {
> > "Prefer strscpy over strlcpy - see: https://github.com/KSPP/linux/issues/89\n" . $herecurr);
> > }
> >
> > +# strlcat uses that should likely be
> > + if ($line =~ /\bstrlcat\s*\(/ && !is_userspace($realfile)) {
> > + WARN("STRLCAT",
> > + "Prefer seq_buf_printf() over strlcat - see: https://github.com/KSPP/linux/issues/370\n" . $herecurr);
> > + }
>
> Using seq_buf_printf() requires switching over to the seq_buf API in
> general, it is not just a simple substitution, so this advice may prove
> unhelpful to many.
And I'm not sure the external url is a good idea.
>
> jon
>
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Greg KH @ 2026-05-11 17:28 UTC (permalink / raw)
To: Willy Tarreau
Cc: Leon Romanovsky, Jonathan Corbet, skhan, security, workflows,
linux-doc, linux-kernel
In-Reply-To: <20260509094755.2838-3-w@1wt.eu>
On Sat, May 09, 2026 at 11:47:54AM +0200, Willy Tarreau wrote:
> The use of automated tools to find bugs in random locations of the kernel
> induces a raise of security reports even if most of them should just be
> reported as regular bugs. This patch is an attempt at drawing a line
> between what qualifies as a security bug and what does not, hoping to
> improve the situation and ease decision on the reporter's side.
>
> It defers the enumeration to a new file, threat-model.rst, that tries
> to enumerate various classes of issues that are and are not security
> bugs. This should permit to more easily update this file for various
> subsystem-specific rules without having to revisit the security bug
> reporting guide.
>
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Cc: Leon Romanovsky <leon@kernel.org>
> Suggested-by: Leon Romanovsky <leon@kernel.org>
> Suggested-by: Greg KH <gregkh@linuxfoundation.org>
> Reviewed-by: Leon Romanovsky <leon@kernel.org>
> Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
> ---
> Documentation/process/index.rst | 1 +
> Documentation/process/security-bugs.rst | 38 +++-
> Documentation/process/threat-model.rst | 236 ++++++++++++++++++++++++
> 3 files changed, 274 insertions(+), 1 deletion(-)
> create mode 100644 Documentation/process/threat-model.rst
Looks great, thank you!
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Want me to take it through one of my trees now to get it to Linus this
week, or should it go through the documentation tree? Either is fine
with me.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Willy Tarreau @ 2026-05-11 18:03 UTC (permalink / raw)
To: Greg KH
Cc: Leon Romanovsky, Jonathan Corbet, skhan, security, workflows,
linux-doc, linux-kernel
In-Reply-To: <2026051124-afar-renewal-795c@gregkh>
On Mon, May 11, 2026 at 07:28:57PM +0200, Greg KH wrote:
> On Sat, May 09, 2026 at 11:47:54AM +0200, Willy Tarreau wrote:
> > The use of automated tools to find bugs in random locations of the kernel
> > induces a raise of security reports even if most of them should just be
> > reported as regular bugs. This patch is an attempt at drawing a line
> > between what qualifies as a security bug and what does not, hoping to
> > improve the situation and ease decision on the reporter's side.
> >
> > It defers the enumeration to a new file, threat-model.rst, that tries
> > to enumerate various classes of issues that are and are not security
> > bugs. This should permit to more easily update this file for various
> > subsystem-specific rules without having to revisit the security bug
> > reporting guide.
> >
> > Cc: Greg KH <gregkh@linuxfoundation.org>
> > Cc: Leon Romanovsky <leon@kernel.org>
> > Suggested-by: Leon Romanovsky <leon@kernel.org>
> > Suggested-by: Greg KH <gregkh@linuxfoundation.org>
> > Reviewed-by: Leon Romanovsky <leon@kernel.org>
> > Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
> > Signed-off-by: Willy Tarreau <w@1wt.eu>
> > ---
> > Documentation/process/index.rst | 1 +
> > Documentation/process/security-bugs.rst | 38 +++-
> > Documentation/process/threat-model.rst | 236 ++++++++++++++++++++++++
> > 3 files changed, 274 insertions(+), 1 deletion(-)
> > create mode 100644 Documentation/process/threat-model.rst
>
> Looks great, thank you!
>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> Want me to take it through one of my trees now to get it to Linus this
> week, or should it go through the documentation tree? Either is fine
> with me.
Yes, please take it as usual, it's simpler for me and it will likely
allow it to be published ealier, which ultimately should help us
faster ;-)
Thanks!
Willy
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Jonathan Corbet @ 2026-05-11 18:39 UTC (permalink / raw)
To: Willy Tarreau, Greg KH
Cc: Leon Romanovsky, skhan, security, workflows, linux-doc,
linux-kernel
In-Reply-To: <agIZ8zeg3m0xE3yL@1wt.eu>
Willy Tarreau <w@1wt.eu> writes:
>>
>> Looks great, thank you!
>>
>> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>
>> Want me to take it through one of my trees now to get it to Linus this
>> week, or should it go through the documentation tree? Either is fine
>> with me.
>
> Yes, please take it as usual, it's simpler for me and it will likely
> allow it to be published ealier, which ultimately should help us
> faster ;-)
I can ship stuff Linusward quickly too... :) But it's fine if Greg
takes it, of course.
jon
^ permalink raw reply
* Re: [PATCH 1/2] [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: Kees Cook @ 2026-05-11 19:07 UTC (permalink / raw)
To: David Laight
Cc: Geert Uytterhoeven, Manuel Ebner, andy.shevchenko, apw, corbet,
dwaipayanray1, joe, linux-doc, linux-kernel, lukas.bulwahn, skhan,
workflows
In-Reply-To: <20260511142649.463c3ea5@pumpkin>
On Mon, May 11, 2026 at 02:26:49PM +0100, David Laight wrote:
> On Mon, 11 May 2026 13:40:55 +0200
> Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> > Hi Manuel,
> >
> > On Sun, 10 May 2026 at 18:52, Manuel Ebner <manuelebner@mailbox.org> wrote:
> > > add strlcat and alternatives
> >
> > Thanks for your patch!
> >
> > > --- a/Documentation/process/deprecated.rst
> > > +++ b/Documentation/process/deprecated.rst
> > > @@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is strscpy(),
> > > though care must be given to any cases where the return value of strlcpy()
> > > is used, since strscpy() will return negative errno values when it truncates.
> > >
> > > +strlcat()
> > > +---------
> > > +strlcat() must re-scan the destination string from the beginning on each
> > > +call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
> > > +snprintf() and scnprintf()
> >
> > The last two not only require the caller to keep track of the offset
> > in the buffer, but also using "%s" when storing passed strings.
>
> Which also means they are significantly slower.
> Mind you, some code has:
> strlcat(buf, "\n", SIZE);
> return strlen(buf);
> which carefully scans the string twice.
> Since the '\0' isn't always needed (eg 'show' functions), this can be:
> len = strlen(buf);
> buf[len] ='\n';
> return len + 1;
> Of course, the code could often easily get the length by other means.
I think I'd prefer to only recommend using seq_buf API. Or for sysfs,
sysfs_emit() as seq_buf hasn't been extended there yet.
-Kees
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Willy Tarreau @ 2026-05-11 20:26 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Greg KH, Leon Romanovsky, skhan, security, workflows, linux-doc,
linux-kernel
In-Reply-To: <878q9pvlif.fsf@trenco.lwn.net>
Hi Jon!
On Mon, May 11, 2026 at 12:39:20PM -0600, Jonathan Corbet wrote:
> Willy Tarreau <w@1wt.eu> writes:
>
> >>
> >> Looks great, thank you!
> >>
> >> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >>
> >> Want me to take it through one of my trees now to get it to Linus this
> >> week, or should it go through the documentation tree? Either is fine
> >> with me.
> >
> > Yes, please take it as usual, it's simpler for me and it will likely
> > allow it to be published ealier, which ultimately should help us
> > faster ;-)
>
> I can ship stuff Linusward quickly too... :) But it's fine if Greg
> takes it, of course.
Oh that's fine then. I thought you only delivered such updates into next
releases. I'm fine with either way of course! Let's pick the path of
least effort for each.
Thank you!
Willy
^ permalink raw reply
* Re: [PATCH 1/2] [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: David Laight @ 2026-05-11 20:34 UTC (permalink / raw)
To: Kees Cook
Cc: Geert Uytterhoeven, Manuel Ebner, andy.shevchenko, apw, corbet,
dwaipayanray1, joe, linux-doc, linux-kernel, lukas.bulwahn, skhan,
workflows
In-Reply-To: <202605111206.ECA86141@keescook>
On Mon, 11 May 2026 12:07:38 -0700
Kees Cook <kees@kernel.org> wrote:
> On Mon, May 11, 2026 at 02:26:49PM +0100, David Laight wrote:
> > On Mon, 11 May 2026 13:40:55 +0200
> > Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >
> > > Hi Manuel,
> > >
> > > On Sun, 10 May 2026 at 18:52, Manuel Ebner <manuelebner@mailbox.org> wrote:
> > > > add strlcat and alternatives
> > >
> > > Thanks for your patch!
> > >
> > > > --- a/Documentation/process/deprecated.rst
> > > > +++ b/Documentation/process/deprecated.rst
> > > > @@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is strscpy(),
> > > > though care must be given to any cases where the return value of strlcpy()
> > > > is used, since strscpy() will return negative errno values when it truncates.
> > > >
> > > > +strlcat()
> > > > +---------
> > > > +strlcat() must re-scan the destination string from the beginning on each
> > > > +call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
> > > > +snprintf() and scnprintf()
> > >
> > > The last two not only require the caller to keep track of the offset
> > > in the buffer, but also using "%s" when storing passed strings.
> >
> > Which also means they are significantly slower.
> > Mind you, some code has:
> > strlcat(buf, "\n", SIZE);
> > return strlen(buf);
> > which carefully scans the string twice.
> > Since the '\0' isn't always needed (eg 'show' functions), this can be:
> > len = strlen(buf);
> > buf[len] ='\n';
> > return len + 1;
> > Of course, the code could often easily get the length by other means.
>
> I think I'd prefer to only recommend using seq_buf API. Or for sysfs,
> sysfs_emit() as seq_buf hasn't been extended there yet.
True for the docs, but rather more work when you are just trying to
get rid of strcpy() and strcat() calls.
It can be hard working out whether you can use sysfs_emit() or not.
(And I recently failed to find where the PAGE_SIZE buffer is
actually allocated; I'm sure it should just be 4k.)
-- David
>
> -Kees
>
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Jonathan Corbet @ 2026-05-11 20:42 UTC (permalink / raw)
To: Willy Tarreau
Cc: Greg KH, Leon Romanovsky, skhan, security, workflows, linux-doc,
linux-kernel
In-Reply-To: <agI7XogSmfN_Pm4t@1wt.eu>
Willy Tarreau <w@1wt.eu> writes:
>> I can ship stuff Linusward quickly too... :) But it's fine if Greg
>> takes it, of course.
>
> Oh that's fine then. I thought you only delivered such updates into next
> releases. I'm fine with either way of course! Let's pick the path of
> least effort for each.
That's my normal procedure, since there are few docs changes that have
greater urgency, but I do have a "fixes" branch.
Greg, what's your preference? Unless I hear otherwise, I guess I'll
apply it shortly.
Thanks,
jon
^ permalink raw reply
* [PATCH] docs: fix spelling of Shepherd in howto
From: Chen-Shi-Hong @ 2026-05-12 0:09 UTC (permalink / raw)
To: corbet; +Cc: skhan, workflows, linux-doc, linux-kernel, Chen-Shi-Hong
Correct the spelling of "Shepherd" in the acknowledgements section of
Documentation/process/howto.rst.
Signed-off-by: Chen-Shi-Hong <eric039eric@gmail.com>
---
Documentation/process/howto.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
index 9438e03d6f50..edf4412de112 100644
--- a/Documentation/process/howto.rst
+++ b/Documentation/process/howto.rst
@@ -616,7 +616,7 @@ Huizenga for some of the list of things you should and should not say.
Also thanks to Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,
Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi
Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,
-David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepard for
+David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepherd for
their review, comments, and contributions. Without their help, this
document would not have been possible.
base-commit: 5d6919055dec134de3c40167a490f33c74c12581
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] docs: fix spelling of Shepherd in howto
From: Randy Dunlap @ 2026-05-12 0:41 UTC (permalink / raw)
To: Chen-Shi-Hong, corbet; +Cc: skhan, workflows, linux-doc, linux-kernel
In-Reply-To: <20260512000946.3234-1-eric039eric@gmail.com>
Hi,
On 5/11/26 5:09 PM, Chen-Shi-Hong wrote:
> Correct the spelling of "Shepherd" in the acknowledgements section of
> Documentation/process/howto.rst.
How do you know that the last name is misspelled?
I found email from "Alex Shepard" on lore.kernel.org/all/ but none from
Alex Shepherd.
https://lore.kernel.org/all/1137702713.3205.43.camel@athena.sea.amer.gettywan.com/
Names can often be spelled many ways.
> Signed-off-by: Chen-Shi-Hong <eric039eric@gmail.com>
> ---
> Documentation/process/howto.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/process/howto.rst b/Documentation/process/howto.rst
> index 9438e03d6f50..edf4412de112 100644
> --- a/Documentation/process/howto.rst
> +++ b/Documentation/process/howto.rst
> @@ -616,7 +616,7 @@ Huizenga for some of the list of things you should and should not say.
> Also thanks to Pat Mochel, Hanna Linder, Randy Dunlap, Kay Sievers,
> Vojtech Pavlik, Jan Kara, Josh Boyer, Kees Cook, Andrew Morton, Andi
> Kleen, Vadim Lobanov, Jesper Juhl, Adrian Bunk, Keri Harris, Frans Pop,
> -David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepard for
> +David A. Wheeler, Junio Hamano, Michael Kerrisk, and Alex Shepherd for
> their review, comments, and contributions. Without their help, this
> document would not have been possible.
>
>
> base-commit: 5d6919055dec134de3c40167a490f33c74c12581
--
~Randy
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Greg KH @ 2026-05-12 5:46 UTC (permalink / raw)
To: Jonathan Corbet
Cc: Willy Tarreau, Leon Romanovsky, skhan, security, workflows,
linux-doc, linux-kernel
In-Reply-To: <87a4u5u195.fsf@trenco.lwn.net>
On Mon, May 11, 2026 at 02:42:14PM -0600, Jonathan Corbet wrote:
> Willy Tarreau <w@1wt.eu> writes:
>
> >> I can ship stuff Linusward quickly too... :) But it's fine if Greg
> >> takes it, of course.
> >
> > Oh that's fine then. I thought you only delivered such updates into next
> > releases. I'm fine with either way of course! Let's pick the path of
> > least effort for each.
>
> That's my normal procedure, since there are few docs changes that have
> greater urgency, but I do have a "fixes" branch.
>
> Greg, what's your preference? Unless I hear otherwise, I guess I'll
> apply it shortly.
Please apply it and take it through your tree, thanks!
greg k-h
^ permalink raw reply
* Re: [PATCH v3 2/3] Documentation: security-bugs: explain what is and is not a security bug
From: Willy Tarreau @ 2026-05-12 5:54 UTC (permalink / raw)
To: Greg KH
Cc: Jonathan Corbet, Leon Romanovsky, skhan, security, workflows,
linux-doc, linux-kernel
In-Reply-To: <2026051220-fetal-obituary-bb2b@gregkh>
On Tue, May 12, 2026 at 07:46:34AM +0200, Greg KH wrote:
> On Mon, May 11, 2026 at 02:42:14PM -0600, Jonathan Corbet wrote:
> > Willy Tarreau <w@1wt.eu> writes:
> >
> > >> I can ship stuff Linusward quickly too... :) But it's fine if Greg
> > >> takes it, of course.
> > >
> > > Oh that's fine then. I thought you only delivered such updates into next
> > > releases. I'm fine with either way of course! Let's pick the path of
> > > least effort for each.
> >
> > That's my normal procedure, since there are few docs changes that have
> > greater urgency, but I do have a "fixes" branch.
> >
> > Greg, what's your preference? Unless I hear otherwise, I guess I'll
> > apply it shortly.
>
> Please apply it and take it through your tree, thanks!
Thanks to you both!
Willy
^ permalink raw reply
* Re: [PATCH 2/2] scripts: checkpatch.pl: add warning for strlcat()
From: Manuel Ebner @ 2026-05-12 7:36 UTC (permalink / raw)
To: David Laight, Jonathan Corbet
Cc: andy.shevchenko, apw, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <20260511142745.7757b1b2@pumpkin>
On Mon, 2026-05-11 at 14:27 +0100, David Laight wrote:
> On Mon, 11 May 2026 06:12:36 -0600
> Jonathan Corbet <corbet@lwn.net> wrote:
>
> > Manuel Ebner <manuelebner@mailbox.org> writes:
> >
> > > add a warning for strlcat()
> > >
> > > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> > > ---
> > > scripts/checkpatch.pl | 6 ++++++
> > > 1 file changed, 6 insertions(+)
> > >
> > > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > > index 0492d6afc9a1..ca1a8e67d529 100755
> > > --- a/scripts/checkpatch.pl
> > > +++ b/scripts/checkpatch.pl
> > > @@ -7085,6 +7085,12 @@ sub process {
> > > "Prefer strscpy over strlcpy - see:
> > > https://github.com/KSPP/linux/issues/89\n" . $herecurr);
Here you can see the external urls already deployed. there are two more in
the code blocks above.
> > > }
> > >
> > > +# strlcat uses that should likely be
> > > + if ($line =~ /\bstrlcat\s*\(/ && !is_userspace($realfile)) {
> > > + WARN("STRLCAT",
> > > + "Prefer seq_buf_printf() over strlcat - see:
> > > https://github.com/KSPP/linux/issues/370\n" . $herecurr);
> > > + }
> >
> > Using seq_buf_printf() requires switching over to the seq_buf API in
> > general, it is not just a simple substitution, so this advice may prove
> > unhelpful to many.
>
> And I'm not sure the external url is a good idea.
It wasn't my idea originally. but I'm open to suggestions.
Manuel
> >
> > jon
> >
^ permalink raw reply
* Re: [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: Jani Nikula @ 2026-05-12 8:52 UTC (permalink / raw)
To: Manuel Ebner, manuelebner
Cc: andy.shevchenko, apw, corbet, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <20260510165451.57674-2-manuelebner@mailbox.org>
On Sun, 10 May 2026, Manuel Ebner <manuelebner@mailbox.org> wrote:
> add strlcat and alternatives
You'd think it's the strlcat() definition that needs a comment above it
saying it's deprecated. I don't think folks really look at
deprecated.rst.
BR,
Jani.
>
> Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> ---
> Documentation/process/deprecated.rst | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
> index fed56864d036..b8a65c19796c 100644
> --- a/Documentation/process/deprecated.rst
> +++ b/Documentation/process/deprecated.rst
> @@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is strscpy(),
> though care must be given to any cases where the return value of strlcpy()
> is used, since strscpy() will return negative errno values when it truncates.
>
> +strlcat()
> +---------
> +strlcat() must re-scan the destination string from the beginning on each
> +call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
> +snprintf() and scnprintf()
> +
> %p format specifier
> -------------------
> Traditionally, using "%p" in format strings would lead to regular address
--
Jani Nikula, Intel
^ permalink raw reply
* Re: [PATCH 1/2] Doc: deprecated.rst: add strlcat()
From: Manuel Ebner @ 2026-05-12 10:43 UTC (permalink / raw)
To: Jani Nikula
Cc: andy.shevchenko, apw, corbet, dwaipayanray1, joe, kees, linux-doc,
linux-kernel, lukas.bulwahn, skhan, workflows
In-Reply-To: <748c2c3d549740918e14f29aa25dd475b99c1313@intel.com>
On Tue, 2026-05-12 at 11:52 +0300, Jani Nikula wrote:
> On Sun, 10 May 2026, Manuel Ebner <manuelebner@mailbox.org> wrote:
> > add strlcat and alternatives
>
> You'd think it's the strlcat() definition that needs a comment above it
> saying it's deprecated. I don't think folks really look at
> deprecated.rst.
arch/s390/lib/string.c
lib/string.c
and
tools/include/nolibc/string.h
do not mentions anything about obsolete.
include/linux/fortify-string.h has
/* Defined after fortified strlen() to reuse it. */
extern size_t __real_strlcat(char *p, const char *q, size_t avail) __RENAME(strlcat);
/**
* strlcat - Append a string to an existing string
* [...]
* Do not use this function. While FORTIFY_SOURCE tries to avoid
* read and write overflows, this is only possible when the sizes
* of @p and @q are known to the compiler. Prefer building the
* string with formatting, via scnprintf(), seq_buf, or similar.
should i add this to the former three files?
Manuel
>
> BR,
> Jani.
>
> >
> > Signed-off-by: Manuel Ebner <manuelebner@mailbox.org>
> > ---
> > Documentation/process/deprecated.rst | 6 ++++++
> > 1 file changed, 6 insertions(+)
> >
> > diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
> > index fed56864d036..b8a65c19796c 100644
> > --- a/Documentation/process/deprecated.rst
> > +++ b/Documentation/process/deprecated.rst
> > @@ -162,6 +162,12 @@ if a source string is not NUL-terminated. The safe replacement is
> > strscpy(),
> > though care must be given to any cases where the return value of strlcpy()
> > is used, since strscpy() will return negative errno values when it truncates.
> >
> > +strlcat()
> > +---------
> > +strlcat() must re-scan the destination string from the beginning on each
> > +call (O(n^2) behavior). Alternatives are seq_buf_puts(), seq_buf_printf(),
> > +snprintf() and scnprintf()
> > +
> > %p format specifier
> > -------------------
> > Traditionally, using "%p" in format strings would lead to regular address
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox