* Re: [PATCH v2] docs: process: email-client: add Thunderbird "Toggle Line Wrap" extension
From: Jonathan Corbet @ 2026-01-06 21:38 UTC (permalink / raw)
To: Vincent Mailhol
Cc: workflows, linux-doc, linux-kernel, Sotir Danailov,
Giedrius Statkevičius, Paul McQuade, Jan Kiszka,
Randy Dunlap, Vincent Mailhol
In-Reply-To: <20251226-docs_thunderbird-toggle-line-wrap-v2-1-aebb8c60025d@kernel.org>
Vincent Mailhol <mailhol@kernel.org> writes:
> While reading the git-format-patch manpages [1], I discovered the existence
> of the "Toggle Line Wrap" extension for Thunderbird which I found rather
> convenient.
>
> Looking at the history, the ancestor of this extension was added to the
> documentation in commit e0e34e977a7c ("Documentation/email-clients.txt:
> update Thunderbird docs with wordwrap plugin") but then removed in commit
> f9a0974d3f70 ("Documentation: update thunderbird email client settings").
>
> Extend the paragraph on Thunderbird's mailnews.wraplength register to
> mention the existence of the "Toggle Line Wrap" extension. The goal is not
> to create a war on what is the best option so make it clear that this is
> just an alternative.
>
> [1] man git-format-patch -- §Thunderbird
> Link: https://git-scm.com/docs/git-format-patch#_thunderbird
>
> Signed-off-by: Vincent Mailhol <mailhol@kernel.org>
> ---
> Changes in v2:
>
> - Use the international URL (remove "fr/")
>
> Link to v1: https://lore.kernel.org/r/20251225-docs_thunderbird-toggle-line-wrap-v1-1-24794afa4abf@kernel.org
> ---
> Documentation/process/email-clients.rst | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] Doc: correct spelling and wording mistakes
From: Jonathan Corbet @ 2026-01-06 21:40 UTC (permalink / raw)
To: Volodymyr Kot; +Cc: workflows, linux-doc, linux-kernel, Volodymyr Kot
In-Reply-To: <20251225133911.87512-1-volodymyr.kot.ua@gmail.com>
Volodymyr Kot <volodymyr.kot.ua@gmail.com> writes:
> Fixed capitalization and punctuation in process documentation.
>
> Signed-off-by: Volodymyr Kot <volodymyr.kot.ua@gmail.com>
> ---
> Documentation/process/1.Intro.rst | 2 +-
> Documentation/process/2.Process.rst | 2 +-
> Documentation/process/4.Coding.rst | 6 +++---
> Documentation/process/7.AdvancedTopics.rst | 2 +-
> 4 files changed, 6 insertions(+), 6 deletions(-)
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH] docs: submitting-patches: suggest adding previous version links
From: Jonathan Corbet @ 2026-01-06 21:53 UTC (permalink / raw)
To: SeongJae Park; +Cc: SeongJae Park, linux-doc, linux-kernel, workflows
In-Reply-To: <20251225015447.16387-1-sj@kernel.org>
SeongJae Park <sj@kernel.org> writes:
> For review of patches that revisioned multiple times, patch changelogs
> are very useful. Adding actual links to the previous versions can
> further help the review. Using such links, reviewers can double check
> the changelog by themselves, and find previous discussions. Nowadays
> having such links (e.g., lore.kernel.org archive links) is easy and
> reliable. Suggest adding such links if available.
>
> Signed-off-by: SeongJae Park <sj@kernel.org>
> ---
> Documentation/process/submitting-patches.rst | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index 9a509f1a6873..e69d19ad658f 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -805,7 +805,8 @@ not part of the changelog which gets committed to the git tree. It is
> additional information for the reviewers. If it's placed above the
> commit tags, it needs manual interaction to remove it. If it is below
> the separator line, it gets automatically stripped off when applying the
> -patch::
> +patch. If available, adding links to previous versions of the patch (e.g.,
> +lore.kernel.org archive link) is recommended to help reviewers::
>
> <commit message>
> ...
> @@ -814,6 +815,9 @@ patch::
> V2 -> V3: Removed redundant helper function
> V1 -> V2: Cleaned up coding style and addressed review comments
>
> + v2: https://lore.kernel.org/bar
> + v1: https://lore.kernel.org/foo
> +
Applied, thanks.
jon
^ permalink raw reply
* Re: [PATCH 4/9] CodingStyle: mention "typedef struct S {} S;" if typedef is used
From: Krzysztof Kozlowski @ 2026-01-07 12:22 UTC (permalink / raw)
To: Alexey Dobriyan, Greg KH; +Cc: corbet, workflows, linux-kernel
In-Reply-To: <55373914-e6e3-490f-9d79-5321f908701e@p183>
On 13/05/2025 20:34, Alexey Dobriyan wrote:
> On Sat, May 10, 2025 at 08:18:53AM +0200, Greg KH wrote:
>> On Fri, May 09, 2025 at 11:34:25PM +0300, Alexey Dobriyan wrote:
>>> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
>>> ---
>>> Documentation/process/coding-style.rst | 14 ++++++++++++++
>>> 1 file changed, 14 insertions(+)
>>
>> We can't take patches without any changelog text, sorry.
>
> The changelog is in the patch itself but OK.
No, there is no such test in the patch itself.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 1/9] CodingStyle: make Documentation/CodingStyle into symlink
From: Krzysztof Kozlowski @ 2026-01-07 12:27 UTC (permalink / raw)
To: Alexey Dobriyan, Al Viro; +Cc: Jonathan Corbet, workflows, linux-kernel
In-Reply-To: <0e43117a-d92c-4563-ad2d-de6cbd02e986@p183>
On 13/05/2025 20:33, Alexey Dobriyan wrote:
> On Tue, May 13, 2025 at 05:12:49AM +0100, Al Viro wrote:
>> On Mon, May 12, 2025 at 07:08:53PM +0300, Alexey Dobriyan wrote:
>>
>>> I split them like referendum ballots to see where the consensus at and
>>> not have big single discussion thread.
>>
>> Just in case - consensus would look like a lot of replies in support and not
>> simply the lack of replies, right?
>
> Well, it is l-k, so absence of NAKs counts as OK.
So let me respond with NAKs...
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 6/9] CodingStyle: recommend static_assert/_Static_assert
From: Krzysztof Kozlowski @ 2026-01-07 12:28 UTC (permalink / raw)
To: Alexey Dobriyan, corbet; +Cc: workflows, linux-kernel
In-Reply-To: <20250509203430.3448-6-adobriyan@gmail.com>
On 09/05/2025 22:34, Alexey Dobriyan wrote:
> Linux's BUG_ON is done backwards (condition is inverted).
> But it is a long story.
>
> However C11/C23 allow to partially transition to what all normal
> programmers are used to, namely assert().
>
> Deprecate BUILD_BUG_ON, recommend static_assert/_Static_assert.
> And then some day BUG_ON will be flipped as well.
NAK, so silence won't be treated as agreement.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 7/9] CodingStyle: new variable declaration placement rule
From: Krzysztof Kozlowski @ 2026-01-07 12:28 UTC (permalink / raw)
To: Alexey Dobriyan, corbet; +Cc: workflows, linux-kernel
In-Reply-To: <20250509203430.3448-7-adobriyan@gmail.com>
On 09/05/2025 22:34, Alexey Dobriyan wrote:
>
> +Variable declarations
> +---------------------
> +
> +Each variable is declared in the innermost scope possible
> +where ``for`` initialization clause counts as a scope as well.
> +
> +Inside specific scope each variable is declared as late as possible as if
> +declarations have "mass" and "fall down":
> +
> +.. code-block:: c
> +
> + int f(void *priv)
> + {
> + struct xxx_obj *obj = to_xxx_obj(priv);
> +
> + rcu_read_lock();
> + int s_xxx = 0;
NAK, so silence won't be treated as agreement.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 8/9] CodingStyle: tell people how to split long "for" loops
From: Krzysztof Kozlowski @ 2026-01-07 12:29 UTC (permalink / raw)
To: Alexey Dobriyan, corbet; +Cc: workflows, linux-kernel
In-Reply-To: <20250509203430.3448-8-adobriyan@gmail.com>
On 09/05/2025 22:34, Alexey Dobriyan wrote:
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
> ---
> Documentation/process/coding-style.rst | 16 +++++++++++++++-
> 1 file changed, 15 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
> index e17de69845ff..494ab3201112 100644
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @@ -183,7 +183,21 @@ Descendants are always substantially shorter than the parent and
> are placed substantially to the right. A very commonly used style
> is to align descendants to a function open parenthesis.
>
> -These same rules are applied to function headers with a long argument list.
> +These same rules are applied to function prototypes with a long argument list.
> +
> +Very long ``for`` loops are split at the ``;`` characters making it easier
> +to see which code goes to which clause:
> +
> +.. code-block:: c
> +
> + for (int i = 0;
> + i < N;
> + i += 1)
> + {
> + }
> +
> +Opening curly is placed on a separate line then to make it easier to tell
> +loop body from iteration clause.
NAK. Very long loops should simply not be written.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 9/9] CodingStyle: flip the rule about curlies
From: Krzysztof Kozlowski @ 2026-01-07 12:29 UTC (permalink / raw)
To: Alexey Dobriyan, corbet; +Cc: workflows, linux-kernel
In-Reply-To: <20250509203430.3448-9-adobriyan@gmail.com>
On 09/05/2025 22:34, Alexey Dobriyan wrote:
> Require set of curlies {} in all if/else branches and all loops
> not matter how simple.
>
> The rationale is that maintaining curlies increases churn and make
> patches bigger when those if/else branches grow and shrink so it is
> easier to always add them.
>
> There are more important things in life than herding curlies.
NAK, so silence won't be treated as agreement.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 9/9] CodingStyle: flip the rule about curlies
From: Krzysztof Kozlowski @ 2026-01-07 12:32 UTC (permalink / raw)
To: Alexey Dobriyan, corbet; +Cc: workflows, linux-kernel
In-Reply-To: <9ab99620-5f17-4f99-b07b-74f445a23e46@kernel.org>
On 07/01/2026 13:29, Krzysztof Kozlowski wrote:
> On 09/05/2025 22:34, Alexey Dobriyan wrote:
>> Require set of curlies {} in all if/else branches and all loops
>> not matter how simple.
>>
>> The rationale is that maintaining curlies increases churn and make
>> patches bigger when those if/else branches grow and shrink so it is
>> easier to always add them.
>>
>> There are more important things in life than herding curlies.
>
>
> NAK, so silence won't be treated as agreement.
... and I failed to notice that this thread was dug up by one person and
it is way forgotten. Sorry for the noise.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] LICENSES: Explicitly allow SPDX-FileCopyrightText
From: Krzysztof Kozlowski @ 2026-01-07 17:12 UTC (permalink / raw)
To: Thomas Gleixner, Greg Kroah-Hartman, Jonathan Corbet,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
linux-spdx, workflows, linux-doc, linux-kernel
Cc: Krzysztof Kozlowski
Sources already have SPDX-FileCopyrightText (~40 instances) and more
appear on the mailing list, so document that it is allowed. On the
other hand SPDX defines several other tags like SPDX-FileType, so add
checkpatch rule to narrow desired tags only to two of them - license and
copyright. That way no new tags would sneak in to the kernel unnoticed.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Other way would be to remove SPDX-FileCopyrightText from existing files
and disallow this, but one way or another we should be explicit about
it. Otherwise people will be sending more of these and each maintainer
would need to make their own call.
---
Documentation/process/license-rules.rst | 2 ++
scripts/checkpatch.pl | 9 +++++++++
2 files changed, 11 insertions(+)
diff --git a/Documentation/process/license-rules.rst b/Documentation/process/license-rules.rst
index 59a7832df7d0..8d7c0214f283 100644
--- a/Documentation/process/license-rules.rst
+++ b/Documentation/process/license-rules.rst
@@ -66,6 +66,8 @@ License identifier syntax
'#!PATH_TO_INTERPRETER' in the first line. For those scripts the SPDX
identifier goes into the second line.
+ Identifier line can be followed by another one with SPDX-FileCopyrightText.
+
|
2. Style:
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 362a8d1cd327..98261ee97e2b 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3844,6 +3844,15 @@ sub process {
"Misplaced SPDX-License-Identifier tag - use line $checklicenseline instead\n" . $herecurr);
}
+# check for unused SPDX file tags
+ if ($rawline =~ /\bSPDX-.*:/ &&
+ $rawline !~ /\bSPDX-License-Identifier:/ &&
+ $rawline !~ /\bSPDX-FileCopyrightText:/) {
+ WARN("SPDX_LICENSE_TAG",
+ "Unsupported SPDX tag\n" . $herecurr);
+ }
+
+
# line length limit (with some exclusions)
#
# There are a few types of lines that may extend beyond $max_line_length:
--
2.51.0
^ permalink raw reply related
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Paul E. McKenney @ 2026-01-07 17:56 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-kernel, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Luis Chamberlain, SeongJae Park, Dan Williams,
Steven Rostedt, NeilBrown, Lorenzo Stoakes, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <20260106205105.4037716-1-dave.hansen@linux.intel.com>
On Tue, Jan 06, 2026 at 12:51:05PM -0800, Dave Hansen wrote:
> In the last few years, the capabilities of coding tools have exploded.
> As those capabilities have expanded, contributors and maintainers have
> more and more questions about how and when to apply those
> capabilities.
>
> Add new Documentation to guide contributors on how to best use kernel
> development tools, new and old.
>
> Note, though, there are fundamentally no new or unique rules in this
> new document. It clarifies expectations that the kernel community has
> had for many years. For example, researchers are already asked to
> disclose the tools they use to find issues by
> Documentation/process/researcher-guidelines.rst. This new document
> just reiterates existing best practices for development tooling.
>
> In short: Please show your work and make sure your contribution is
> easy to review.
>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Reviewed-by: Shuah Khan <shuah@kernel.org>
> Reviewed-by: Kees Cook <kees@kernel.org>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
> Reviewed-by: SeongJae Park <sj@kernel.org>
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
> Cc: NeilBrown <neilb@ownmail.net>
> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Theodore Ts'o <tytso@mit.edu>
> Cc: Sasha Levin <sashal@kernel.org>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: workflows@vger.kernel.org
> Cc: ksummit@lists.linux.dev
The "Ask for some other special steps, like asking the contributor to
elaborate on how the tool or model was trained" covers my copyright
concerns, so:
Reviewed-by: Paul E. McKenney <paulmck@kernel.org>
> --
>
> There has been a ton of feedback since v2. Thanks everyone! I've
> tried to respect all of the feedback, but some of it has been
> contradictory and I haven't been able to incorporate everything.
>
> Please speak up if I missed something important here.
>
> Changes from v2:
> * Mention testing (Shuah)
> * Remove "very", rename LLM => coding assistant (Dan)
> * More formatting sprucing up and minor typos (Miguel)
> * Make changelog and text less flashy (Christian)
> * Tone down critical=>helpful (Neil)
> * Wording/formatting tweaks (Randy)
>
> Changes from v1:
> * Rename to generated-content.rst and add to documentation index.
> (Jon)
> * Rework subject to align with the new filename
> * Replace commercial names with generic ones. (Jon)
> * Be consistent about punctuation at the end of bullets for whole
> sentences. (Miguel)
> * Formatting sprucing up and minor typos (Miguel)
>
> This document was a collaborative effort from all the members of
> the TAB. I just reformatted it into .rst and wrote the changelog.
> ---
> Documentation/process/generated-content.rst | 97 +++++++++++++++++++++
> Documentation/process/index.rst | 1 +
> 2 files changed, 98 insertions(+)
> create mode 100644 Documentation/process/generated-content.rst
>
> diff --git a/Documentation/process/generated-content.rst b/Documentation/process/generated-content.rst
> new file mode 100644
> index 000000000000..917d6e93c66d
> --- /dev/null
> +++ b/Documentation/process/generated-content.rst
> @@ -0,0 +1,97 @@
> +============================================
> +Kernel Guidelines for Tool-Generated Content
> +============================================
> +
> +Purpose
> +=======
> +
> +Kernel contributors have been using tooling to generate contributions
> +for a long time. These tools can increase the volume of contributions.
> +At the same time, reviewer and maintainer bandwidth is a scarce
> +resource. Understanding which portions of a contribution come from
> +humans versus tools is helpful to maintain those resources and keep
> +kernel development healthy.
> +
> +The goal here is to clarify community expectations around tools. This
> +lets everyone become more productive while also maintaining high
> +degrees of trust between submitters and reviewers.
> +
> +Out of Scope
> +============
> +
> +These guidelines do not apply to tools that make trivial tweaks to
> +preexisting content. Nor do they pertain to AI tooling that helps with
> +menial tasks. Some examples:
> +
> + - Spelling and grammar fix ups, like rephrasing to imperative voice
> + - Typing aids like identifier completion, common boilerplate or
> + trivial pattern completion
> + - Purely mechanical transformations like variable renaming
> + - Reformatting, like running Lindent, ``clang-format`` or
> + ``rust-fmt``
> +
> +Even if your tool use is out of scope, you should still always consider
> +if it would help reviewing your contribution if the reviewer knows
> +about the tool that you used.
> +
> +In Scope
> +========
> +
> +These guidelines apply when a meaningful amount of content in a kernel
> +contribution was not written by a person in the Signed-off-by chain,
> +but was instead created by a tool.
> +
> +Detection of a problem and testing the fix for it is also part of the
> +development process; if a tool was used to find a problem addressed by
> +a change, that should be noted in the changelog. This not only gives
> +credit where it is due, it also helps fellow developers find out about
> +these tools.
> +
> +Some examples:
> + - Any tool-suggested fix such as ``checkpatch.pl --fix``
> + - Coccinelle scripts
> + - A chatbot generated a new function in your patch to sort list entries.
> + - A .c file in the patch was originally generated by a coding
> + assistant but cleaned up by hand.
> + - The changelog was generated by handing the patch to a generative AI
> + tool and asking it to write the changelog.
> + - The changelog was translated from another language.
> +
> +If in doubt, choose transparency and assume these guidelines apply to
> +your contribution.
> +
> +Guidelines
> +==========
> +
> +First, read the Developer's Certificate of Origin:
> +Documentation/process/submitting-patches.rst. Its rules are simple
> +and have been in place for a long time. They have covered many
> +tool-generated contributions. Ensure that you understand your entire
> +submission and are prepared to respond to review comments.
> +
> +Second, when making a contribution, be transparent about the origin of
> +content in cover letters and changelogs. You can be more transparent
> +by adding information like this:
> +
> + - What tools were used?
> + - The input to the tools you used, like the Coccinelle source script.
> + - If code was largely generated from a single or short set of
> + prompts, include those prompts. For longer sessions, include a
> + summary of the prompts and the nature of resulting assistance.
> + - Which portions of the content were affected by that tool?
> + - How is the submission tested and what tools were used to test the
> + fix?
> +
> +As with all contributions, individual maintainers have discretion to
> +choose how they handle the contribution. For example, they might:
> +
> + - Treat it just like any other contribution.
> + - Reject it outright.
> + - Treat the contribution specially like reviewing with extra scrutiny,
> + or at a lower priority than human-generated content.
> + - Suggest a better prompt instead of suggesting specific code changes.
> + - Ask for some other special steps, like asking the contributor to
> + elaborate on how the tool or model was trained.
> + - Ask the submitter to explain in more detail about the contribution
> + so that the maintainer can feel comfortable that the submitter fully
> + understands how the code works.
> diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
> index aa12f2660194..e1a8a31389f5 100644
> --- a/Documentation/process/index.rst
> +++ b/Documentation/process/index.rst
> @@ -68,6 +68,7 @@ beyond).
> stable-kernel-rules
> management-style
> researcher-guidelines
> + generated-content
>
> Dealing with bugs
> -----------------
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-07 18:12 UTC (permalink / raw)
To: Dave Hansen
Cc: linux-kernel, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Luis Chamberlain, SeongJae Park, Dan Williams,
Steven Rostedt, NeilBrown, Theodore Ts'o, Sasha Levin,
Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <20260106205105.4037716-1-dave.hansen@linux.intel.com>
On Tue, Jan 06, 2026 at 12:51:05PM -0800, Dave Hansen wrote:
> In the last few years, the capabilities of coding tools have exploded.
> As those capabilities have expanded, contributors and maintainers have
> more and more questions about how and when to apply those
> capabilities.
>
> Add new Documentation to guide contributors on how to best use kernel
> development tools, new and old.
>
> Note, though, there are fundamentally no new or unique rules in this
> new document. It clarifies expectations that the kernel community has
> had for many years. For example, researchers are already asked to
> disclose the tools they use to find issues by
> Documentation/process/researcher-guidelines.rst. This new document
> just reiterates existing best practices for development tooling.
>
> In short: Please show your work and make sure your contribution is
> easy to review.
>
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Reviewed-by: Shuah Khan <shuah@kernel.org>
> Reviewed-by: Kees Cook <kees@kernel.org>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
> Reviewed-by: SeongJae Park <sj@kernel.org>
> Reviewed-by: Dan Williams <dan.j.williams@intel.com>
> Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
> Cc: NeilBrown <neilb@ownmail.net>
> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: Theodore Ts'o <tytso@mit.edu>
> Cc: Sasha Levin <sashal@kernel.org>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: workflows@vger.kernel.org
> Cc: ksummit@lists.linux.dev
>
> --
>
> There has been a ton of feedback since v2. Thanks everyone! I've
> tried to respect all of the feedback, but some of it has been
> contradictory and I haven't been able to incorporate everything.
>
> Please speak up if I missed something important here.
Well you ignored my two previous proposals AFAICT so :) [0, 1]
[0]:https://lore.kernel.org/all/c8d9f4fc-332f-4df8-9620-e0e2aa6dc0e9@lucifer.local/
[1]:https://lore.kernel.org/all/11eaf7fa-27d0-4a57-abf0-5f24c918966c@lucifer.local/
I guess I'll reiterate them below for what it's worth.
>
> Changes from v2:
> * Mention testing (Shuah)
> * Remove "very", rename LLM => coding assistant (Dan)
> * More formatting sprucing up and minor typos (Miguel)
> * Make changelog and text less flashy (Christian)
> * Tone down critical=>helpful (Neil)
> * Wording/formatting tweaks (Randy)
>
> Changes from v1:
> * Rename to generated-content.rst and add to documentation index.
> (Jon)
> * Rework subject to align with the new filename
> * Replace commercial names with generic ones. (Jon)
> * Be consistent about punctuation at the end of bullets for whole
> sentences. (Miguel)
> * Formatting sprucing up and minor typos (Miguel)
>
> This document was a collaborative effort from all the members of
> the TAB. I just reformatted it into .rst and wrote the changelog.
> ---
> Documentation/process/generated-content.rst | 97 +++++++++++++++++++++
> Documentation/process/index.rst | 1 +
> 2 files changed, 98 insertions(+)
> create mode 100644 Documentation/process/generated-content.rst
>
> diff --git a/Documentation/process/generated-content.rst b/Documentation/process/generated-content.rst
> new file mode 100644
> index 000000000000..917d6e93c66d
> --- /dev/null
> +++ b/Documentation/process/generated-content.rst
> @@ -0,0 +1,97 @@
> +============================================
> +Kernel Guidelines for Tool-Generated Content
> +============================================
> +
> +Purpose
> +=======
> +
> +Kernel contributors have been using tooling to generate contributions
> +for a long time. These tools can increase the volume of contributions.
> +At the same time, reviewer and maintainer bandwidth is a scarce
> +resource. Understanding which portions of a contribution come from
> +humans versus tools is helpful to maintain those resources and keep
> +kernel development healthy.
> +
> +The goal here is to clarify community expectations around tools. This
> +lets everyone become more productive while also maintaining high
> +degrees of trust between submitters and reviewers.
I feel that LLMs are not like any other tools but in fact represent
something entirely new in that you can end-to-end send patches using this
tooling with little to no knowledge and the asymmetry between maintainer
resource and the possible slurry of submissions that might arise makes this
very significantly different.
I know Linus had the cute interpretation of it 'just being another tool'
but never before have people been able to do this.
So I think this continues to be something that should be underlined, and
for it to be put more forthrightly that if such 'slop' series are sent they
can be dismissed without further discussion.
This my the primary concern with these tools, and this document is far too
hand-wavey about it in my view + doesn't really address that at all.
> +
> +Out of Scope
> +============
> +
> +These guidelines do not apply to tools that make trivial tweaks to
> +preexisting content. Nor do they pertain to AI tooling that helps with
> +menial tasks. Some examples:
> +
> + - Spelling and grammar fix ups, like rephrasing to imperative voice
> + - Typing aids like identifier completion, common boilerplate or
> + trivial pattern completion
> + - Purely mechanical transformations like variable renaming
> + - Reformatting, like running Lindent, ``clang-format`` or
> + ``rust-fmt``
> +
> +Even if your tool use is out of scope, you should still always consider
> +if it would help reviewing your contribution if the reviewer knows
> +about the tool that you used.
> +
> +In Scope
> +========
> +
> +These guidelines apply when a meaningful amount of content in a kernel
> +contribution was not written by a person in the Signed-off-by chain,
> +but was instead created by a tool.
> +
> +Detection of a problem and testing the fix for it is also part of the
> +development process; if a tool was used to find a problem addressed by
> +a change, that should be noted in the changelog. This not only gives
> +credit where it is due, it also helps fellow developers find out about
> +these tools.
> +
> +Some examples:
> + - Any tool-suggested fix such as ``checkpatch.pl --fix``
> + - Coccinelle scripts
> + - A chatbot generated a new function in your patch to sort list entries.
> + - A .c file in the patch was originally generated by a coding
> + assistant but cleaned up by hand.
> + - The changelog was generated by handing the patch to a generative AI
> + tool and asking it to write the changelog.
> + - The changelog was translated from another language.
> +
> +If in doubt, choose transparency and assume these guidelines apply to
> +your contribution.
> +
> +Guidelines
> +==========
> +
> +First, read the Developer's Certificate of Origin:
> +Documentation/process/submitting-patches.rst. Its rules are simple
> +and have been in place for a long time. They have covered many
> +tool-generated contributions. Ensure that you understand your entire
> +submission and are prepared to respond to review comments.
> +
> +Second, when making a contribution, be transparent about the origin of
> +content in cover letters and changelogs. You can be more transparent
> +by adding information like this:
> +
> + - What tools were used?
> + - The input to the tools you used, like the Coccinelle source script.
> + - If code was largely generated from a single or short set of
> + prompts, include those prompts. For longer sessions, include a
> + summary of the prompts and the nature of resulting assistance.
> + - Which portions of the content were affected by that tool?
> + - How is the submission tested and what tools were used to test the
> + fix?
> +
> +As with all contributions, individual maintainers have discretion to
> +choose how they handle the contribution. For example, they might:
> +
> + - Treat it just like any other contribution.
> + - Reject it outright.
This is really not correct, it's simply not acceptable in the community to
reject series outright without justification. Yes perhaps people do that,
but it's really not something that's accepted.
So again trying to squeezed this into the cute 'hey it's just like any
other tooling!' box doesn't work.
We should highlight that this is something _different_ from other such
series.
Again, I feel the document fails to highlight the biggest concern around
LLMs.
> + - Treat the contribution specially like reviewing with extra scrutiny,
> + or at a lower priority than human-generated content.
> + - Suggest a better prompt instead of suggesting specific code changes.
> + - Ask for some other special steps, like asking the contributor to
> + elaborate on how the tool or model was trained.
> + - Ask the submitter to explain in more detail about the contribution
> + so that the maintainer can feel comfortable that the submitter fully
> + understands how the code works.
> diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
> index aa12f2660194..e1a8a31389f5 100644
> --- a/Documentation/process/index.rst
> +++ b/Documentation/process/index.rst
> @@ -68,6 +68,7 @@ beyond).
> stable-kernel-rules
> management-style
> researcher-guidelines
> + generated-content
>
> Dealing with bugs
> -----------------
> --
> 2.34.1
>
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH] LICENSES: Explicitly allow SPDX-FileCopyrightText
From: Joe Perches @ 2026-01-07 18:40 UTC (permalink / raw)
To: Krzysztof Kozlowski, Thomas Gleixner, Greg Kroah-Hartman,
Jonathan Corbet, Andy Whitcroft, Dwaipayan Ray, Lukas Bulwahn,
linux-spdx, workflows, linux-doc, linux-kernel
Cc: Linus Torvalds
In-Reply-To: <20260107171246.242973-2-krzysztof.kozlowski@oss.qualcomm.com>
On Wed, 2026-01-07 at 18:12 +0100, Krzysztof Kozlowski wrote:
> Sources already have SPDX-FileCopyrightText (~40 instances) and more
> appear on the mailing list, so document that it is allowed. On the
> other hand SPDX defines several other tags like SPDX-FileType, so add
> checkpatch rule to narrow desired tags only to two of them - license and
> copyright. That way no new tags would sneak in to the kernel unnoticed.
I find no value in this tag. I think it should be discouraged.
How is it different or more useful than a typical Copyright or © symbol ?
^ permalink raw reply
* Re: [PATCH] LICENSES: Explicitly allow SPDX-FileCopyrightText
From: Greg Kroah-Hartman @ 2026-01-07 18:52 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Thomas Gleixner, Jonathan Corbet, Andy Whitcroft, Joe Perches,
Dwaipayan Ray, Lukas Bulwahn, linux-spdx, workflows, linux-doc,
linux-kernel
In-Reply-To: <20260107171246.242973-2-krzysztof.kozlowski@oss.qualcomm.com>
On Wed, Jan 07, 2026 at 06:12:47PM +0100, Krzysztof Kozlowski wrote:
> Sources already have SPDX-FileCopyrightText (~40 instances) and more
> appear on the mailing list, so document that it is allowed. On the
> other hand SPDX defines several other tags like SPDX-FileType, so add
> checkpatch rule to narrow desired tags only to two of them - license and
> copyright. That way no new tags would sneak in to the kernel unnoticed.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Other way would be to remove SPDX-FileCopyrightText from existing files
> and disallow this, but one way or another we should be explicit about
> it. Otherwise people will be sending more of these and each maintainer
> would need to make their own call.
> ---
> Documentation/process/license-rules.rst | 2 ++
> scripts/checkpatch.pl | 9 +++++++++
> 2 files changed, 11 insertions(+)
>
> diff --git a/Documentation/process/license-rules.rst b/Documentation/process/license-rules.rst
> index 59a7832df7d0..8d7c0214f283 100644
> --- a/Documentation/process/license-rules.rst
> +++ b/Documentation/process/license-rules.rst
> @@ -66,6 +66,8 @@ License identifier syntax
> '#!PATH_TO_INTERPRETER' in the first line. For those scripts the SPDX
> identifier goes into the second line.
As you are adding a copyright identifier, this sentence should probably
be:
For those scripts, the SPDX license identifier goes into the
second line.
> + Identifier line can be followed by another one with SPDX-FileCopyrightText.
How about:
"The license identifier line can then be followed by a
SPDX-FileCopyrightText line if desired."
> +
> |
>
> 2. Style:
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 362a8d1cd327..98261ee97e2b 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3844,6 +3844,15 @@ sub process {
> "Misplaced SPDX-License-Identifier tag - use line $checklicenseline instead\n" . $herecurr);
> }
>
> +# check for unused SPDX file tags
# check for unsupported SPDX file tags
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Dave Hansen @ 2026-01-07 19:18 UTC (permalink / raw)
To: Lorenzo Stoakes, Dave Hansen
Cc: linux-kernel, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Luis Chamberlain, SeongJae Park, Dan Williams,
Steven Rostedt, NeilBrown, Theodore Ts'o, Sasha Levin,
Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <1e982055-47c2-43d1-a919-93b3e59f2ed0@lucifer.local>
On 1/7/26 10:12, Lorenzo Stoakes wrote:
...
> I know Linus had the cute interpretation of it 'just being another tool'
> but never before have people been able to do this.
I respect your position here. But I'm not sure how to reconcile:
LLMs are just another tool
and
LLMs are not just another tool
:)
Let's look at it another way: What we all *want* for the kernel is
simplicity. Simple rules, simple documentation, simple code. The
simplest way to deal with the LLM onslaught is to pray that our existing
rules will suffice.
For now, I think the existing rules are holding. We have the luxury of
treating LLMs like any other tool. That could change any day because
some new tool comes along that's better at spamming patches at us. I
think that's the point you're trying to make is that the dam might break
any day and we should be prepared for it.
Is that what it boils down to?
>> +As with all contributions, individual maintainers have discretion to
>> +choose how they handle the contribution. For example, they might:
>> +
>> + - Treat it just like any other contribution.
>> + - Reject it outright.
>
> This is really not correct, it's simply not acceptable in the community to
> reject series outright without justification. Yes perhaps people do that,
> but it's really not something that's accepted.
I'm not quite sure how this gives maintainers a new ability to reject
things without justification, or encourages them to reject
tool-generated code in a new way.
Let's say something generated by "checkpatch.pl --fix" that's trying to
patch arch/x86/foo.c lands in my inbox. I personally think it's OK for
me as a maintainer to say: "No thanks, checkpatch has burned me too many
times in foo.c and I don't trust its output there." To me, that's
rejecting it outright.
Could you explain a bit how this might encourage bad maintainer behavior?
^ permalink raw reply
* Re: [PATCH] LICENSES: Explicitly allow SPDX-FileCopyrightText
From: Greg Kroah-Hartman @ 2026-01-07 19:35 UTC (permalink / raw)
To: Joe Perches
Cc: Krzysztof Kozlowski, Thomas Gleixner, Jonathan Corbet,
Andy Whitcroft, Dwaipayan Ray, Lukas Bulwahn, linux-spdx,
workflows, linux-doc, linux-kernel, Linus Torvalds
In-Reply-To: <4702253d918c8edb899a91fbd79b40199a013264.camel@perches.com>
On Wed, Jan 07, 2026 at 10:40:11AM -0800, Joe Perches wrote:
> On Wed, 2026-01-07 at 18:12 +0100, Krzysztof Kozlowski wrote:
> > Sources already have SPDX-FileCopyrightText (~40 instances) and more
> > appear on the mailing list, so document that it is allowed. On the
> > other hand SPDX defines several other tags like SPDX-FileType, so add
> > checkpatch rule to narrow desired tags only to two of them - license and
> > copyright. That way no new tags would sneak in to the kernel unnoticed.
>
> I find no value in this tag. I think it should be discouraged.
>
> How is it different or more useful than a typical Copyright or © symbol ?
It's easier to parse automatically and put into other places (like a
software bill of materials).
I don't like it all that much either, as really, it doesn't mean much
(go talk to a lawyer for details), but it's already in our tree so we
might as well document it...
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH] LICENSES: Explicitly allow SPDX-FileCopyrightText
From: Laurent Pinchart @ 2026-01-07 19:29 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Krzysztof Kozlowski, Thomas Gleixner, Jonathan Corbet,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
linux-spdx, workflows, linux-doc, linux-kernel
In-Reply-To: <2026010724-activate-saggy-9c08@gregkh>
On Wed, Jan 07, 2026 at 07:52:31PM +0100, Greg KH wrote:
> On Wed, Jan 07, 2026 at 06:12:47PM +0100, Krzysztof Kozlowski wrote:
> > Sources already have SPDX-FileCopyrightText (~40 instances) and more
> > appear on the mailing list, so document that it is allowed. On the
> > other hand SPDX defines several other tags like SPDX-FileType, so add
> > checkpatch rule to narrow desired tags only to two of them - license and
> > copyright. That way no new tags would sneak in to the kernel unnoticed.
> >
> > Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> >
> > ---
> >
> > Other way would be to remove SPDX-FileCopyrightText from existing files
> > and disallow this, but one way or another we should be explicit about
> > it. Otherwise people will be sending more of these and each maintainer
> > would need to make their own call.
> > ---
> > Documentation/process/license-rules.rst | 2 ++
> > scripts/checkpatch.pl | 9 +++++++++
> > 2 files changed, 11 insertions(+)
> >
> > diff --git a/Documentation/process/license-rules.rst b/Documentation/process/license-rules.rst
> > index 59a7832df7d0..8d7c0214f283 100644
> > --- a/Documentation/process/license-rules.rst
> > +++ b/Documentation/process/license-rules.rst
> > @@ -66,6 +66,8 @@ License identifier syntax
> > '#!PATH_TO_INTERPRETER' in the first line. For those scripts the SPDX
> > identifier goes into the second line.
>
> As you are adding a copyright identifier, this sentence should probably
> be:
> For those scripts, the SPDX license identifier goes into the
> second line.
>
> > + Identifier line can be followed by another one with SPDX-FileCopyrightText.
>
> How about:
>
> "The license identifier line can then be followed by a
> SPDX-FileCopyrightText line if desired."
I'd write "by one of multiple" instead of "by a" as multiple copyright
owners for the same file is common in the kernel.
> > +
> > |
> >
> > 2. Style:
> > diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> > index 362a8d1cd327..98261ee97e2b 100755
> > --- a/scripts/checkpatch.pl
> > +++ b/scripts/checkpatch.pl
> > @@ -3844,6 +3844,15 @@ sub process {
> > "Misplaced SPDX-License-Identifier tag - use line $checklicenseline instead\n" . $herecurr);
> > }
> >
> > +# check for unused SPDX file tags
>
> # check for unsupported SPDX file tags
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] LICENSES: Explicitly allow SPDX-FileCopyrightText
From: Joe Perches @ 2026-01-07 19:38 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Krzysztof Kozlowski, Thomas Gleixner, Jonathan Corbet,
Andy Whitcroft, Dwaipayan Ray, Lukas Bulwahn, linux-spdx,
workflows, linux-doc, linux-kernel, Linus Torvalds
In-Reply-To: <2026010726-crusader-recoup-4825@gregkh>
On Wed, 2026-01-07 at 20:35 +0100, Greg Kroah-Hartman wrote:
> On Wed, Jan 07, 2026 at 10:40:11AM -0800, Joe Perches wrote:
> > On Wed, 2026-01-07 at 18:12 +0100, Krzysztof Kozlowski wrote:
> > > Sources already have SPDX-FileCopyrightText (~40 instances) and more
> > > appear on the mailing list, so document that it is allowed. On the
> > > other hand SPDX defines several other tags like SPDX-FileType, so add
> > > checkpatch rule to narrow desired tags only to two of them - license and
> > > copyright. That way no new tags would sneak in to the kernel unnoticed.
> >
> > I find no value in this tag. I think it should be discouraged.
> >
> > How is it different or more useful than a typical Copyright or © symbol ?
>
> It's easier to parse automatically and put into other places (like a
> software bill of materials).
>
> I don't like it all that much either, as really, it doesn't mean much
> (go talk to a lawyer for details), but it's already in our tree so we
> might as well document it...
Document it doesn't mean encourage it.
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-07 21:15 UTC (permalink / raw)
To: Dave Hansen
Cc: Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Dan Williams, Steven Rostedt, NeilBrown, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <93aadf2b-0df4-49eb-91fd-b401b44ce3af@sr71.net>
On Wed, Jan 07, 2026 at 11:18:52AM -0800, Dave Hansen wrote:
> On 1/7/26 10:12, Lorenzo Stoakes wrote:
> ...
> > I know Linus had the cute interpretation of it 'just being another tool'
> > but never before have people been able to do this.
>
> I respect your position here. But I'm not sure how to reconcile:
>
> LLMs are just another tool
> and
> LLMs are not just another tool
>
> :)
Well I'm not asking you to reconcile that, I'm providing my point of view
which disagrees with the first position and makes a case for the
second. Isn't review about feedback both positive and negative?
Obviously if this was intended to simply inform the community of the
committee's decision then apologies for misinterpreting it.
I would simply argue that LLMs are not another tool on the basis of the
drastic negative impact its had in very many areas, for which you need only
take a cursory glance at the world to observe.
Thinking LLMs are 'just another tool' is to say effectively that the kernel
is immune from this. Which seems to me a silly position.
>
> Let's look at it another way: What we all *want* for the kernel is
> simplicity. Simple rules, simple documentation, simple code. The
> simplest way to deal with the LLM onslaught is to pray that our existing
> rules will suffice.
I'm not sure we really have rules quite as clearly as you say, as
subsystems differ greatly in what they do.
For one mm merges patches unless averse review is received. Which means a
sudden influx of LLM series is likely to lead to real problems. Not all
subsystems are alike like this.
One rule that seems consistent is that arbitrary dismissal of series is
seriously frowned upon.
The document claims otherwise.
>
> For now, I think the existing rules are holding. We have the luxury of
We're noticing a lot more LLM slop than we used to. It is becoming more and
more of an issue.
Secondly, as I said in my MS thread and maybe even in a previous version of
this one (can't remember) - I fear that once it becomes public that we are
open to LLM patches, the floodgates will open.
The kernel has a thorny reputation of people pushing back, which probably
plays some role in holding that off.
And it's not like I'm asking for much, I'm not asking you to rewrite the
document, or take an entirely different approach, I'm just saying that we
should highlight that :
1. LLMs _allow you to send patches end-to-end without expertise_.
2. As a result, even though the community (rightly) strongly disapproves of
blanket dismissals of series, if we suspect AI slop [I think it's useful
to actually use that term], maintains can reject it out of hand.
Point 2 is absolutely a new thing in my view.
> treating LLMs like any other tool. That could change any day because
> some new tool comes along that's better at spamming patches at us. I
> think that's the point you're trying to make is that the dam might break
> any day and we should be prepared for it.
>
> Is that what it boils down to?
I feel I've answered that above.
>
> >> +As with all contributions, individual maintainers have discretion to
> >> +choose how they handle the contribution. For example, they might:
> >> +
> >> + - Treat it just like any other contribution.
> >> + - Reject it outright.
> >
> > This is really not correct, it's simply not acceptable in the community to
> > reject series outright without justification. Yes perhaps people do that,
> > but it's really not something that's accepted.
>
> I'm not quite sure how this gives maintainers a new ability to reject
> things without justification, or encourages them to reject
> tool-generated code in a new way.
>
> Let's say something generated by "checkpatch.pl --fix" that's trying to
> patch arch/x86/foo.c lands in my inbox. I personally think it's OK for
> me as a maintainer to say: "No thanks, checkpatch has burned me too many
> times in foo.c and I don't trust its output there." To me, that's
> rejecting it outright.
>
> Could you explain a bit how this might encourage bad maintainer behavior?
I really don't understand your question or why you're formulating this to
be about bad maintainer behaviour?
It's generally frowned upon in the kernel to outright reject series without
technical justification. I really don't see how you can say that is not the
case?
LLM generated series won't be a trivial checkpatch.pl --fix change, you've
given a trivially identifiable case that you could absolutely justify.
Again, I'm not really asking for much here. As a maintainer I am (very)
concerned about the asymmetry between what can be submitted vs. review
resource.
And to me being able to reference this document and to say 'sorry this
appears to be AI slop so we can't accept it' would be really useful.
Referencing a document that tries very hard to say 'NOP' isn't quite so
useful.
Thanks, Lorenzo
^ permalink raw reply
* Re: [PATCH] LICENSES: Explicitly allow SPDX-FileCopyrightText
From: Krzysztof Kozlowski @ 2026-01-07 21:28 UTC (permalink / raw)
To: Joe Perches, Greg Kroah-Hartman
Cc: Thomas Gleixner, Jonathan Corbet, Andy Whitcroft, Dwaipayan Ray,
Lukas Bulwahn, linux-spdx, workflows, linux-doc, linux-kernel,
Linus Torvalds
In-Reply-To: <dc44dd2c6efb16ace506085922707c70126117e7.camel@perches.com>
On 07/01/2026 20:38, Joe Perches wrote:
> On Wed, 2026-01-07 at 20:35 +0100, Greg Kroah-Hartman wrote:
>> On Wed, Jan 07, 2026 at 10:40:11AM -0800, Joe Perches wrote:
>>> On Wed, 2026-01-07 at 18:12 +0100, Krzysztof Kozlowski wrote:
>>>> Sources already have SPDX-FileCopyrightText (~40 instances) and more
>>>> appear on the mailing list, so document that it is allowed. On the
>>>> other hand SPDX defines several other tags like SPDX-FileType, so add
>>>> checkpatch rule to narrow desired tags only to two of them - license and
>>>> copyright. That way no new tags would sneak in to the kernel unnoticed.
>>>
>>> I find no value in this tag. I think it should be discouraged.
>>>
>>> How is it different or more useful than a typical Copyright or © symbol ?
>>
>> It's easier to parse automatically and put into other places (like a
>> software bill of materials).
>>
>> I don't like it all that much either, as really, it doesn't mean much
>> (go talk to a lawyer for details), but it's already in our tree so we
>> might as well document it...
>
> Document it doesn't mean encourage it.
Just like I explained in the changelog --- part, we should either accept
it or mark it as incorrect in the checkpatch. I am fine with both (I
don't have actual preference), but what I do not want is to have it in
limbo/open stage, where everyone has to guess if it is desired/allowed.
Lack of documented policy enforced by checkpatch means every maintainer
upon seeing it will do the same as me - git grep and try to understand
whether this is approved or not. Pretty waste of everyone's time.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Steven Rostedt @ 2026-01-07 21:58 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Dave Hansen, Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Dan Williams, NeilBrown, Theodore Ts'o, Sasha Levin,
Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <1c74353c-40de-4d0b-a517-92a94f8b4af8@lucifer.local>
On Wed, 7 Jan 2026 21:15:17 +0000
Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> I would simply argue that LLMs are not another tool on the basis of the
> drastic negative impact its had in very many areas, for which you need only
> take a cursory glance at the world to observe.
>
> Thinking LLMs are 'just another tool' is to say effectively that the kernel
> is immune from this. Which seems to me a silly position.
But has this started to become a real problem with the kernel today?
>
> >
> > Let's look at it another way: What we all *want* for the kernel is
> > simplicity. Simple rules, simple documentation, simple code. The
> > simplest way to deal with the LLM onslaught is to pray that our existing
> > rules will suffice.
>
> I'm not sure we really have rules quite as clearly as you say, as
> subsystems differ greatly in what they do.
>
> For one mm merges patches unless averse review is received. Which means a
> sudden influx of LLM series is likely to lead to real problems. Not all
> subsystems are alike like this.
But has this happened yet?
>
> One rule that seems consistent is that arbitrary dismissal of series is
> seriously frowned upon.
If it is AI slop coming in, you can say, "unless you can prove to me that
you understand this series and there's nothing wrong with it, I'm rejecting
it"
If the series looks good then what's the issue. But if it's AI slop and
it's obvious the person behind the code doesn't understand what they are
submitting, that could even be rationale for sending that person to your
/dev/null folder.
>
> The document claims otherwise.
>
> >
> > For now, I think the existing rules are holding. We have the luxury of
>
> We're noticing a lot more LLM slop than we used to. It is becoming more and
> more of an issue.
Are you noticing this in submissions?
>
> Secondly, as I said in my MS thread and maybe even in a previous version of
> this one (can't remember) - I fear that once it becomes public that we are
> open to LLM patches, the floodgates will open.
This document is not about addressing anything that we fear will happen. It
is only to state our current view of how things work today.
If the floodgates do open and we get inundated with AI slop, then we can
most definitely update his document to have a bit more teeth.
But one thing I learned about my decade on the TAB, is don't worry about
things you are afraid might happen, just make sure you address what is
currently happening. Especially when it's easy to update the rules.
>
> The kernel has a thorny reputation of people pushing back, which probably
> plays some role in holding that off.
>
> And it's not like I'm asking for much, I'm not asking you to rewrite the
> document, or take an entirely different approach, I'm just saying that we
> should highlight that :
>
> 1. LLMs _allow you to send patches end-to-end without expertise_.
Why does this need to be added to the document. I think we should only be
addressing how we handle tool generated content.
>
> 2. As a result, even though the community (rightly) strongly disapproves of
> blanket dismissals of series, if we suspect AI slop [I think it's useful
> to actually use that term], maintains can reject it out of hand.
>
> Point 2 is absolutely a new thing in my view.
I don't believe that is necessary. I reject patches outright all the time.
Especially checkpatch "fixes" on code that is already in the tree. I just
say: "checkpatch is for patches, not accepted content. If it's not a real
bug, don't use checkpatch."
If the AI code is decent, why reject it? If it's slop, then yeah, you have
a lot of reasons to reject it.
>
> > treating LLMs like any other tool. That could change any day because
> > some new tool comes along that's better at spamming patches at us. I
> > think that's the point you're trying to make is that the dam might break
> > any day and we should be prepared for it.
> >
> > Is that what it boils down to?
>
> I feel I've answered that above.
>
> >
> > >> +As with all contributions, individual maintainers have discretion to
> > >> +choose how they handle the contribution. For example, they might:
> > >> +
> > >> + - Treat it just like any other contribution.
> > >> + - Reject it outright.
> > >
> > > This is really not correct, it's simply not acceptable in the community to
> > > reject series outright without justification. Yes perhaps people do that,
> > > but it's really not something that's accepted.
> >
> > I'm not quite sure how this gives maintainers a new ability to reject
> > things without justification, or encourages them to reject
> > tool-generated code in a new way.
> >
> > Let's say something generated by "checkpatch.pl --fix" that's trying to
> > patch arch/x86/foo.c lands in my inbox. I personally think it's OK for
> > me as a maintainer to say: "No thanks, checkpatch has burned me too many
> > times in foo.c and I don't trust its output there." To me, that's
> > rejecting it outright.
> >
> > Could you explain a bit how this might encourage bad maintainer behavior?
>
> I really don't understand your question or why you're formulating this to
> be about bad maintainer behaviour?
>
> It's generally frowned upon in the kernel to outright reject series without
> technical justification. I really don't see how you can say that is not the
> case?
If it's AI slop, then I'm sure you could easily find lots of technical
justifications for rejecting it. Why do we need to explicitly state it
here?.
>
> LLM generated series won't be a trivial checkpatch.pl --fix change, you've
> given a trivially identifiable case that you could absolutely justify.
Is it trivial just because it's checkpatch? I gave another example above
too. But if AI slop is coming in, I'm sure there's lots of reasons to
reject it.
Are you saying that if there's good AI code coming in (I wouldn't call it
slop then) that you want to outright reject it too?
>
> Again, I'm not really asking for much here. As a maintainer I am (very)
> concerned about the asymmetry between what can be submitted vs. review
> resource.
>
> And to me being able to reference this document and to say 'sorry this
> appears to be AI slop so we can't accept it' would be really useful.
Then why not come up with a list of reasons AI slop is bad and make a
boiler plate and send that every time. Basically states that if you submit
AI code, the burden is on the submitter to prove that they understand the
code. Or would you like that explicitly stated in this document? Something
like:
- If you submit any type of tool generated code, then it is the
responsibility of the submitter to prove to the maintainer that they
understand the code that they are submitting. Otherwise the maintainer
may simply reject the changes outright.
?
>
> Referencing a document that tries very hard to say 'NOP' isn't quite so
> useful.
I don't think this document's goal was to be a pointer to show people why
you are rejecting AI submissions. This is just a guideline to how tool
generated code should be submitted.
It's about how things work today. It's not about how things will work going
forward with AI submissions. That document is for another day.
-- Steve
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: James Bottomley @ 2026-01-07 22:39 UTC (permalink / raw)
To: Lorenzo Stoakes, Dave Hansen
Cc: Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Dan Williams, Steven Rostedt, NeilBrown, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <1c74353c-40de-4d0b-a517-92a94f8b4af8@lucifer.local>
On Wed, 2026-01-07 at 21:15 +0000, Lorenzo Stoakes wrote:
> On Wed, Jan 07, 2026 at 11:18:52AM -0800, Dave Hansen wrote:
> > On 1/7/26 10:12, Lorenzo Stoakes wrote:
> > ...
> > > I know Linus had the cute interpretation of it 'just being
> > > another tool' but never before have people been able to do this.
> >
> > I respect your position here. But I'm not sure how to reconcile:
> >
> > LLMs are just another tool
> > and
> > LLMs are not just another tool
> >
> > :)
>
> Well I'm not asking you to reconcile that, I'm providing my point of
> view which disagrees with the first position and makes a case for the
> second. Isn't review about feedback both positive and negative?
>
> Obviously if this was intended to simply inform the community of the
> committee's decision then apologies for misinterpreting it.
>
> I would simply argue that LLMs are not another tool on the basis of
> the drastic negative impact its had in very many areas, for which you
> need only take a cursory glance at the world to observe.
>
> Thinking LLMs are 'just another tool' is to say effectively that the
> kernel is immune from this. Which seems to me a silly position.
All tools are double edged and the better a tool is the more
problematic its harmful uses become but people often use them anyway
because of the beneficial uses. You don't for instance classify
chainsaws as not another tool because they can be used to deforest the
Amazon. All the document is saying is that we start from the place of
treating AI like any other tool and, like any other tool, if it proves
to cause way more problems than it solves, then we can then move on to
other things. There are other tools we've tried and abandoned (like
compiling the kernel with c++), so this really isn't any different.
Regards,
James
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: dan.j.williams @ 2026-01-07 23:50 UTC (permalink / raw)
To: Lorenzo Stoakes, Dave Hansen
Cc: Dave Hansen, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, SeongJae Park,
Dan Williams, Steven Rostedt, NeilBrown, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <1c74353c-40de-4d0b-a517-92a94f8b4af8@lucifer.local>
Lorenzo Stoakes wrote:
[..]
> And it's not like I'm asking for much, I'm not asking you to rewrite the
> document, or take an entirely different approach, I'm just saying that we
> should highlight that :
>
> 1. LLMs _allow you to send patches end-to-end without expertise_.
>
> 2. As a result, even though the community (rightly) strongly disapproves of
> blanket dismissals of series, if we suspect AI slop [I think it's useful
> to actually use that term], maintains can reject it out of hand.
>
> Point 2 is absolutely a new thing in my view.
I worry what this sentiment does to the health of the project. Is
"hunting for slop" really what we want to be doing? When the accusation
is false, what then?
If the goal of the wording change is to give cover and license for that
kind of activity, I have a hard time seeing that as good for the
project.
It has always been the case that problematic submitters put stress on
maintainer bandwidth. Having a name for one class of potential
maintainer stress in a process document does not advance the status quo.
A maintainer is trusted to maintain the code and have always been able
to give feedback of "I don't like it, leaves a bad taste", "I don't
trust it does what it claims", or "I don't trust you, $submitter, to be
able to maintain the implications of this proposal long term". That
feedback is not strictly technical, but it is more actionable than "this
is AI slop".
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: SeongJae Park @ 2026-01-08 0:00 UTC (permalink / raw)
To: Dave Hansen
Cc: SeongJae Park, linux-kernel, Shuah Khan, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Luis Chamberlain, Dan Williams,
Steven Rostedt, NeilBrown, Lorenzo Stoakes, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <20260106205105.4037716-1-dave.hansen@linux.intel.com>
Nit. Apparently this is v4, not v3? I show v3 from
https://lore.kernel.org/20251114183528.1239900-1-dave.hansen@linux.intel.com
On Tue, 6 Jan 2026 12:51:05 -0800 Dave Hansen <dave.hansen@linux.intel.com> wrote:
[...]
Thanks,
SJ
^ 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