* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Steven Rostedt @ 2025-11-15 19:02 UTC (permalink / raw)
To: Dave Hansen
Cc: dave, Shuah Khan, Kees Cook, Greg Kroah-Hartman, Miguel Ojeda,
NeilBrown, Lorenzo Stoakes, Dan Williams, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <20251114183528.1239900-1-dave.hansen@linux.intel.com>
On Fri, 14 Nov 2025 10:35:28 -0800
Dave Hansen <dave.hansen@linux.intel.com> 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 in
> 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.
Thanks Dave for pushing this through!
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
-- Steve
>
> 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>
> 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
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Thomas Gleixner @ 2025-11-15 15:22 UTC (permalink / raw)
To: Dave Hansen, dave
Cc: Dave Hansen, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, NeilBrown, Lorenzo Stoakes, Dan Williams,
Theodore Ts'o, Sasha Levin, Jonathan Corbet, Vlastimil Babka,
workflows, ksummit
In-Reply-To: <20251114183528.1239900-1-dave.hansen@linux.intel.com>
On Fri, Nov 14 2025 at 10:35, Dave Hansen wrote:
> +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.
Can we pretty please define a tag and format for this?
I'm not really interested in the creative ways which will otherwise make
change logs even more incomprehensible.
Thanks
tglx
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: dan.j.williams @ 2025-11-14 23:19 UTC (permalink / raw)
To: Dave Hansen, dave
Cc: Dave Hansen, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, NeilBrown, Lorenzo Stoakes, Dan Williams,
Theodore Ts'o, Sasha Levin, Jonathan Corbet, Vlastimil Babka,
workflows, ksummit
In-Reply-To: <20251114183528.1239900-1-dave.hansen@linux.intel.com>
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 in
> 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>
> Cc: NeilBrown <neilb@ownmail.net>
> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
All my concerns have been addressed.
Reviewed-by: Dan Williams <dan.j.williams@intel.com>
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Dave Hansen @ 2025-11-14 22:53 UTC (permalink / raw)
To: SeongJae Park, Dave Hansen
Cc: dave, Shuah Khan, Kees Cook, Greg Kroah-Hartman, Miguel Ojeda,
NeilBrown, Lorenzo Stoakes, Dan Williams, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <20251114201738.3212-1-sj@kernel.org>
On 11/14/25 12:17, SeongJae Park wrote:
>> + - Treat the contribution specially like reviewing with extra scrutiny,
>> + or at a lower priority than human-generated content
> Nit. The ending period is missed?
Fixed, thanks!
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Dave Hansen @ 2025-11-14 22:52 UTC (permalink / raw)
To: Luis Chamberlain, Dave Hansen, Julia Lawall, Linus Torvalds,
Takashi Iwai
Cc: dave, Shuah Khan, Kees Cook, Greg Kroah-Hartman, Miguel Ojeda,
NeilBrown, Lorenzo Stoakes, Dan Williams, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <aReMPda2sowBpkO-@bombadil.infradead.org>
On 11/14/25 12:08, Luis Chamberlain wrote:
...>> + - What tools were used?
>
> I really think we should just recommend the user to *consider* using:
>
> Generated-by
>
> I've been using it for Coccinelle on Linux for years, and it was not
> just me. In other projects, in particular kdevops we started using this
> to also be clear about the use of AI tools, and I've found it
> instrumental to keep track of how much code *does not use it*.
That sounds like a reasonable enough idea. But I think it's mostly
orthogonal to this document. If there were Generated-by documentation in
submitting-patches.rst, it would definitely get a special mention here.
>> + - 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.
>
> A long time ago we evaluated the question of using git notes for
> coccinelle used input, and the issue back then was we didn't have support
> for it I think. But I think that hump is gone?
>
> If so, would using git notes for prompts be useful in this case as we scale
> tooling outside of Coccinelle, like AI prompts? I believe this can be
> instrumental for enhancing LLMs as well for fine tuned LLMs for Linux
> development.
I looked at git notes a bit during the Link: tag discussion. There still
seem to be a few humps left, like git needing special configuration not
to lose notes on "git commit --amend" or rebases.
They seem to be _getting_ there, but they certainly don't seem to be a
nice, seamless thing that can easily be put into everyone's existing
workflows.
> Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Thanks!
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: SeongJae Park @ 2025-11-14 20:17 UTC (permalink / raw)
To: Dave Hansen
Cc: SeongJae Park, dave, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, NeilBrown, Lorenzo Stoakes, Dan Williams,
Theodore Ts'o, Sasha Levin, Jonathan Corbet, Vlastimil Babka,
workflows, ksummit
In-Reply-To: <20251114183528.1239900-1-dave.hansen@linux.intel.com>
On Fri, 14 Nov 2025 10:35:28 -0800 Dave Hansen <dave.hansen@linux.intel.com> 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.
Thank you for writing this!
[...]
> +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
Nit. The ending period is missed?
Reviewed-by: SeongJae Park <sj@kernel.org>
Thanks,
SJ
[...]
Sent using hkml (https://github.com/sjp38/hackermail)
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Luis Chamberlain @ 2025-11-14 20:08 UTC (permalink / raw)
To: Dave Hansen, Julia Lawall, Linus Torvalds, Takashi Iwai
Cc: dave, Shuah Khan, Kees Cook, Greg Kroah-Hartman, Miguel Ojeda,
NeilBrown, Lorenzo Stoakes, Dan Williams, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Vlastimil Babka, workflows, ksummit
In-Reply-To: <20251114183528.1239900-1-dave.hansen@linux.intel.com>
On Fri, Nov 14, 2025 at 10:35:28AM -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 in
> 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>
> 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.
>
> 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)
>
> 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 | 96 +++++++++++++++++++++
> Documentation/process/index.rst | 1 +
> 2 files changed, 97 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 0000000000000..acdf23819d685
> --- /dev/null
> +++ b/Documentation/process/generated-content.rst
> @@ -0,0 +1,96 @@
> +============================================
> +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?
I really think we should just recommend the user to *consider* using:
Generated-by
I've been using it for Coccinelle on Linux for years, and it was not
just me. In other projects, in particular kdevops we started using this
to also be clear about the use of AI tools, and I've found it
instrumental to keep track of how much code *does not use it*.
> + - 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.
A long time ago we evaluated the question of using git notes for
coccinelle used input, and the issue back then was we didn't have support
for it I think. But I think that hump is gone?
If so, would using git notes for prompts be useful in this case as we scale
tooling outside of Coccinelle, like AI prompts? I believe this can be
instrumental for enhancing LLMs as well for fine tuned LLMs for Linux
development.
Otherwise, looks good.
Reviewed-by: Luis Chamberlain <mcgrof@kernel.org>
Luis
^ permalink raw reply
* [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Dave Hansen @ 2025-11-14 18:35 UTC (permalink / raw)
To: dave
Cc: Dave Hansen, Shuah Khan, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, NeilBrown, Lorenzo Stoakes, Dan Williams,
Theodore Ts'o, Sasha Levin, Jonathan Corbet, Vlastimil Babka,
workflows, ksummit
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 in
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>
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.
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)
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 | 96 +++++++++++++++++++++
Documentation/process/index.rst | 1 +
2 files changed, 97 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 0000000000000..acdf23819d685
--- /dev/null
+++ b/Documentation/process/generated-content.rst
@@ -0,0 +1,96 @@
+============================================
+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 tools 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 aa12f26601949..e1a8a31389f53 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 related
* Re: [PATCH v8 00/27] mm/ksw: Introduce KStackWatch debugging tool
From: Jinchao Wang @ 2025-11-13 4:40 UTC (permalink / raw)
To: Matthew Wilcox
Cc: kasan-dev, linux-arm-kernel, linux-doc, linux-kernel, linux-mm,
linux-perf-users, linux-trace-kernel, llvm, workflows, x86
In-Reply-To: <aRTv0eHfX0j8vJOW@casper.infradead.org>
On Wed, Nov 12, 2025 at 08:36:33PM +0000, Matthew Wilcox wrote:
> [dropping all the individual email addresses; leaving only the
> mailing lists]
>
> On Wed, Nov 12, 2025 at 10:14:29AM +0800, Jinchao Wang wrote:
> > On Mon, Nov 10, 2025 at 05:33:22PM +0000, Matthew Wilcox wrote:
> > > On Tue, Nov 11, 2025 at 12:35:55AM +0800, Jinchao Wang wrote:
> > > > Earlier this year, I debugged a stack corruption panic that revealed the
> > > > limitations of existing debugging tools. The bug persisted for 739 days
> > > > before being fixed (CVE-2025-22036), and my reproduction scenario
> > > > differed from the CVE report—highlighting how unpredictably these bugs
> > > > manifest.
> > >
> > > Well, this demonstrates the dangers of keeping this problem siloed
> > > within your own exfat group. The fix made in 1bb7ff4204b6 is wrong!
> > > It was fixed properly in 7375f22495e7 which lists its Fixes: as
> > > Linux-2.6.12-rc2, but that's simply the beginning of git history.
> > > It's actually been there since v2.4.6.4 where it's documented as simply:
> > >
> > > - some subtle fs/buffer.c race conditions (Andrew Morton, me)
> > >
> > > As far as I can tell the changes made in 1bb7ff4204b6 should be
> > > reverted.
> >
> > Thank you for the correction and the detailed history. I wasn't aware this
> > dated back to v2.4.6.4. I'm not part of the exfat group; I simply
> > encountered a bug that 1bb7ff4204b6 happened to resolve in my scenario.
> > The timeline actually illustrates the exact problem KStackWatch addresses:
> > a bug introduced in 2001, partially addressed in 2025, then properly fixed
> > months later. The 24-year gap suggests these silent stack corruptions are
> > extremely difficult to locate.
>
> I think that's a misdiagnosis caused by not understanding the limited
> circumstances in which the problem occurs. To hit this problem, you
> have to have a buffer_head allocated on the stack. That doesn't happen
> in many places:
>
> fs/buffer.c: struct buffer_head tmp = {
> fs/direct-io.c: struct buffer_head map_bh = { 0, };
> fs/ext2/super.c: struct buffer_head tmp_bh;
> fs/ext2/super.c: struct buffer_head tmp_bh;
> fs/ext4/mballoc-test.c: struct buffer_head bitmap_bh;
> fs/ext4/mballoc-test.c: struct buffer_head gd_bh;
> fs/gfs2/bmap.c: struct buffer_head bh;
> fs/gfs2/bmap.c: struct buffer_head bh;
> fs/isofs/inode.c: struct buffer_head dummy;
> fs/jfs/super.c: struct buffer_head tmp_bh;
> fs/jfs/super.c: struct buffer_head tmp_bh;
> fs/mpage.c: struct buffer_head map_bh;
> fs/mpage.c: struct buffer_head map_bh;
>
> It's far more common for buffer_heads to be allocated from slab and
> attached to folios. The other necessary condition to hit this problem
> is that get_block() has to actually read the data from disk. That's
> not normal either! Most filesystems just fill in the metadata about
> the block and defer the actual read to when the data is wanted. That's
> the high-performance way to do it.
>
> So our opportunity to catch this bug was highly limited by the fact that
> we just don't run the codepaths that would allow it to trigger.
>
> > > > Initially, I enabled KASAN, but the bug did not reproduce. Reviewing the
> > > > code in __blk_flush_plug(), I found it difficult to trace all logic
> > > > paths due to indirect function calls through function pointers.
> > >
> > > So why is the solution here not simply to fix KASAN instead of this
> > > giant patch series?
> >
> > KASAN caught 7375f22495e7 because put_bh() accessed bh->b_count after
> > wait_on_buffer() of another thread returned—the stack was invalid.
> > In 1bb7ff4204b6 and my case, corruption occurred before the victim
> > function of another thread returned. The stack remained valid to KASAN,
> > so no warning triggered. This is timing-dependent, not a KASAN deficiency.
>
> I agree that it's a narrow race window, but nevertheless KASAN did catch
> it with ntfs and not with exfat. The KASAN documentation states that
> it can catch this kind of bug:
>
> Generic KASAN supports finding bugs in all of slab, page_alloc, vmap, vmalloc,
> stack, and global memory.
>
> Software Tag-Based KASAN supports slab, page_alloc, vmalloc, and stack memory.
>
> Hardware Tag-Based KASAN supports slab, page_alloc, and non-executable vmalloc
> memory.
>
> (hm, were you using hwkasan instead of swkasan, and that's why you
> couldn't see it?)
>
You're right that these conditions are narrow. However, when these bugs
hit, they're severe and extremely difficult to debug. This year alone,
this specific buffer_head bug was hit at least twice: 1bb7ff4204b6 and my
case. Over 24 years, others likely encountered it but lacked tools to
pinpoint the root cause.
I used software KASAN for the exfat case, but the bug didn't reproduce,
likely due to timing changes from the overhead. More fundamentally, the
corruption was in-bounds within active stack frames, which KASAN cannot
detect by design.
Beyond buffer_head, I encountered another stack corruption bug in network
drivers this year. Without KStackWatch, I had to manually instrument the
code to locate where corruption occurred.
These issues may be more common than they appear. Given Linux's massive
user base combined with the kernel's huge codebase and the large volume of
driver code, both in-tree and out-of-tree, even narrow conditions will be
hit.
Since posting earlier versions, several developers have contacted me about
using KStackWatch for their own issues. KStackWatch fills a gap: it can
pinpoint in-bounds stack corruption with much lower overhead than KASAN.
^ permalink raw reply
* Re: [PATCH v8 00/27] mm/ksw: Introduce KStackWatch debugging tool
From: Matthew Wilcox @ 2025-11-12 20:36 UTC (permalink / raw)
To: Jinchao Wang
Cc: kasan-dev, linux-arm-kernel, linux-doc, linux-kernel, linux-mm,
linux-perf-users, linux-trace-kernel, llvm, workflows, x86
In-Reply-To: <aRLmGxKVvfl5N792@ndev>
[dropping all the individual email addresses; leaving only the
mailing lists]
On Wed, Nov 12, 2025 at 10:14:29AM +0800, Jinchao Wang wrote:
> On Mon, Nov 10, 2025 at 05:33:22PM +0000, Matthew Wilcox wrote:
> > On Tue, Nov 11, 2025 at 12:35:55AM +0800, Jinchao Wang wrote:
> > > Earlier this year, I debugged a stack corruption panic that revealed the
> > > limitations of existing debugging tools. The bug persisted for 739 days
> > > before being fixed (CVE-2025-22036), and my reproduction scenario
> > > differed from the CVE report—highlighting how unpredictably these bugs
> > > manifest.
> >
> > Well, this demonstrates the dangers of keeping this problem siloed
> > within your own exfat group. The fix made in 1bb7ff4204b6 is wrong!
> > It was fixed properly in 7375f22495e7 which lists its Fixes: as
> > Linux-2.6.12-rc2, but that's simply the beginning of git history.
> > It's actually been there since v2.4.6.4 where it's documented as simply:
> >
> > - some subtle fs/buffer.c race conditions (Andrew Morton, me)
> >
> > As far as I can tell the changes made in 1bb7ff4204b6 should be
> > reverted.
>
> Thank you for the correction and the detailed history. I wasn't aware this
> dated back to v2.4.6.4. I'm not part of the exfat group; I simply
> encountered a bug that 1bb7ff4204b6 happened to resolve in my scenario.
> The timeline actually illustrates the exact problem KStackWatch addresses:
> a bug introduced in 2001, partially addressed in 2025, then properly fixed
> months later. The 24-year gap suggests these silent stack corruptions are
> extremely difficult to locate.
I think that's a misdiagnosis caused by not understanding the limited
circumstances in which the problem occurs. To hit this problem, you
have to have a buffer_head allocated on the stack. That doesn't happen
in many places:
fs/buffer.c: struct buffer_head tmp = {
fs/direct-io.c: struct buffer_head map_bh = { 0, };
fs/ext2/super.c: struct buffer_head tmp_bh;
fs/ext2/super.c: struct buffer_head tmp_bh;
fs/ext4/mballoc-test.c: struct buffer_head bitmap_bh;
fs/ext4/mballoc-test.c: struct buffer_head gd_bh;
fs/gfs2/bmap.c: struct buffer_head bh;
fs/gfs2/bmap.c: struct buffer_head bh;
fs/isofs/inode.c: struct buffer_head dummy;
fs/jfs/super.c: struct buffer_head tmp_bh;
fs/jfs/super.c: struct buffer_head tmp_bh;
fs/mpage.c: struct buffer_head map_bh;
fs/mpage.c: struct buffer_head map_bh;
It's far more common for buffer_heads to be allocated from slab and
attached to folios. The other necessary condition to hit this problem
is that get_block() has to actually read the data from disk. That's
not normal either! Most filesystems just fill in the metadata about
the block and defer the actual read to when the data is wanted. That's
the high-performance way to do it.
So our opportunity to catch this bug was highly limited by the fact that
we just don't run the codepaths that would allow it to trigger.
> > > Initially, I enabled KASAN, but the bug did not reproduce. Reviewing the
> > > code in __blk_flush_plug(), I found it difficult to trace all logic
> > > paths due to indirect function calls through function pointers.
> >
> > So why is the solution here not simply to fix KASAN instead of this
> > giant patch series?
>
> KASAN caught 7375f22495e7 because put_bh() accessed bh->b_count after
> wait_on_buffer() of another thread returned—the stack was invalid.
> In 1bb7ff4204b6 and my case, corruption occurred before the victim
> function of another thread returned. The stack remained valid to KASAN,
> so no warning triggered. This is timing-dependent, not a KASAN deficiency.
I agree that it's a narrow race window, but nevertheless KASAN did catch
it with ntfs and not with exfat. The KASAN documentation states that
it can catch this kind of bug:
Generic KASAN supports finding bugs in all of slab, page_alloc, vmap, vmalloc,
stack, and global memory.
Software Tag-Based KASAN supports slab, page_alloc, vmalloc, and stack memory.
Hardware Tag-Based KASAN supports slab, page_alloc, and non-executable vmalloc
memory.
(hm, were you using hwkasan instead of swkasan, and that's why you
couldn't see it?)
^ permalink raw reply
* Re: [PATCH v8 00/27] mm/ksw: Introduce KStackWatch debugging tool
From: Jinchao Wang @ 2025-11-12 2:14 UTC (permalink / raw)
To: Matthew Wilcox
Cc: Andrew Morton, Masami Hiramatsu (Google), Peter Zijlstra,
Randy Dunlap, Marco Elver, Mike Rapoport, Alexander Potapenko,
Adrian Hunter, Alexander Shishkin, Alice Ryhl, Andrey Konovalov,
Andrey Ryabinin, Andrii Nakryiko, Ard Biesheuvel,
Arnaldo Carvalho de Melo, Ben Segall, Bill Wendling,
Borislav Petkov, Catalin Marinas, Dave Hansen, David Hildenbrand,
David Kaplan, David S. Miller, Dietmar Eggemann, Dmitry Vyukov,
H. Peter Anvin, Ian Rogers, Ingo Molnar, James Clark, Jinjie Ruan,
Jiri Olsa, Jonathan Corbet, Juri Lelli, Justin Stitt, kasan-dev,
Kees Cook, Liam R. Howlett, Liang Kan, Linus Walleij,
linux-arm-kernel, linux-doc, linux-kernel, linux-mm,
linux-perf-users, linux-trace-kernel, llvm, Lorenzo Stoakes,
Mark Rutland, Masahiro Yamada, Mathieu Desnoyers, Mel Gorman,
Michal Hocko, Miguel Ojeda, Nam Cao, Namhyung Kim,
Nathan Chancellor, Naveen N Rao, Nick Desaulniers, Rong Xu,
Sami Tolvanen, Steven Rostedt, Suren Baghdasaryan,
Thomas Gleixner, Thomas Weißschuh, Valentin Schneider,
Vincent Guittot, Vincenzo Frascino, Vlastimil Babka, Will Deacon,
workflows, x86
In-Reply-To: <aRIh4pBs7KCDhQOp@casper.infradead.org>
On Mon, Nov 10, 2025 at 05:33:22PM +0000, Matthew Wilcox wrote:
> On Tue, Nov 11, 2025 at 12:35:55AM +0800, Jinchao Wang wrote:
> > Earlier this year, I debugged a stack corruption panic that revealed the
> > limitations of existing debugging tools. The bug persisted for 739 days
> > before being fixed (CVE-2025-22036), and my reproduction scenario
> > differed from the CVE report—highlighting how unpredictably these bugs
> > manifest.
>
> Well, this demonstrates the dangers of keeping this problem siloed
> within your own exfat group. The fix made in 1bb7ff4204b6 is wrong!
> It was fixed properly in 7375f22495e7 which lists its Fixes: as
> Linux-2.6.12-rc2, but that's simply the beginning of git history.
> It's actually been there since v2.4.6.4 where it's documented as simply:
>
> - some subtle fs/buffer.c race conditions (Andrew Morton, me)
>
> As far as I can tell the changes made in 1bb7ff4204b6 should be
> reverted.
Thank you for the correction and the detailed history. I wasn't aware this
dated back to v2.4.6.4. I'm not part of the exfat group; I simply
encountered a bug that 1bb7ff4204b6 happened to resolve in my scenario.
The timeline actually illustrates the exact problem KStackWatch addresses:
a bug introduced in 2001, partially addressed in 2025, then properly fixed
months later. The 24-year gap suggests these silent stack corruptions are
extremely difficult to locate.
>
> > Initially, I enabled KASAN, but the bug did not reproduce. Reviewing the
> > code in __blk_flush_plug(), I found it difficult to trace all logic
> > paths due to indirect function calls through function pointers.
>
> So why is the solution here not simply to fix KASAN instead of this
> giant patch series?
KASAN caught 7375f22495e7 because put_bh() accessed bh->b_count after
wait_on_buffer() of another thread returned—the stack was invalid.
In 1bb7ff4204b6 and my case, corruption occurred before the victim
function of another thread returned. The stack remained valid to KASAN,
so no warning triggered. This is timing-dependent, not a KASAN deficiency.
Making KASAN treat parts of active stack frame as invalid would be
complex and add significant overhead, likely worsening the reproduction
prevention issue. KASAN's overhead already prevented reproduction in my
environment.
KStackWatch takes a different approach: it watches stack frame regardless
of whether KASAN considers them valid or invalid, with much less overhead
thereby preserving reproduction scenarios.
The value proposition:
Finding where corruption occurs is the bottleneck. Once located,
subsystem experts can analyze the root cause. Without that location, even
experts are stuck.
If KStackWatch had existed earlier, this 24-year-old bug might have been
found sooner when someone hit a similar corruption. The same applies to
other stack corruption bugs.
I'd appreciate your thoughts on whether this addresses your concerns.
Best regards,
Jinchao
^ permalink raw reply
* Re: [PATCH] [v2] Documentation: Provide guidelines for tool-generated content
From: Theodore Ts'o @ 2025-11-11 13:08 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Linus Torvalds, H. Peter Anvin, Mike Rapoport, Laurent Pinchart,
Christian Brauner, Dave Hansen, Vlastimil Babka, linux-kernel,
workflows@vger.kernel.org, ksummit@lists.linux.dev,
Steven Rostedt, Dan Williams, Sasha Levin, Jonathan Corbet,
Kees Cook, Greg Kroah-Hartman, Miguel Ojeda, Shuah Khan
In-Reply-To: <8bc25747-fcf0-4e45-b10a-566c5cfe771a@lucifer.local>
On Tue, Nov 11, 2025 at 09:35:18AM +0000, Lorenzo Stoakes wrote:
>
> Now 'any idiot' can fire off hundreds of patches that look at a glance as
> if they might have some validiity.
>
> The asymmetry of this is VERY concerning.
>
> I also hate that we have to think about it, but the second the press put
> out 'the kernel accepts AI patches now!' - and trust me THEY WILL - we are
> likely to see an influx like this that maintainers will have to deal with.
Yeah, that's an argument for not requiring any kind of AI tagging.
One of my concerns is that there's no guarantee that people flooding
the kernel with AI slop won't disclose that they used an LLM.
> 1. Maintains MUST have the ability to JUST SAY NO, go away _en-masse_ to
> regain symmetry on this.
Maintainers do have this already. There are certain people who are
known to be sending low priority patches, and people just quietly
ignore those patches.
The risk of AI slop is that this will just happen a *lot* more often,
which means that patches from known high quality controllers will get
far more attention than patches from newer contributors --- because we
won't know whether it's a new contributor who is coming up to speed,
or someone who is sending AI slop. So the more AI slop we get, the
more this dynamic will accelerate, to the point where people who
accuse us of having an old "boys/girls" club will become true, and
people will accuse us of not being welcoming to new contributors.
There *will* be a solution to the symmetry; so I wouldn't consider it
"unworkable". It's just that we (and especially newcomers) might not
like the solution that naturally comes out of it. As you put it,
"throw out the baby with the bath water"; the system will survive, but
it might suck to be the baby.
> 2. Those who submit patches MUST UNDERSTAND EVERY PART OF IT.
>
> 'that which can be proposed without understanding can be dismissed without
> understanding'.
Yeah, it might be that all we can do is to say that people who use
LLM's without understanding all parts of it, my result in their
blackening their reputation, wiht the result that *all* their patches
might get ignored.
And we can warn that if a company has many of its employees sending
lower quality contributions, maintainers might decide to address the
denial of service attack by ignoring *all* patches from a particular
company / domain. We've done this before, with the University of
Minnesota, due to gross abuse leading to lack of trust of the
institution.
Hopefully things won't come to that, but maybe explicitly warning
people that *is* a possibility might be useful as a deterrent factor.
And I think it's important to say that it's low quality contributions
from AI is no different from any other kind of low quality
contributions. And just as judges in courts of law have sanctioned
lawyers for submitting legal briefs that contained completely
hallucinated court cases, there will be costs to sending cr*p no
matter what the source.
> I think as long as we UNDERLINE these points I think we're good.
>
> TL;DR: we won't take slop.
Agreed, completely.
- Ted
^ permalink raw reply
* Re: [PATCH] [v2] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2025-11-11 9:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Mike Rapoport, Laurent Pinchart,
Christian Brauner, Dave Hansen, Vlastimil Babka, linux-kernel,
workflows@vger.kernel.org, ksummit@lists.linux.dev,
Steven Rostedt, Dan Williams, Theodore Ts'o, Sasha Levin,
Jonathan Corbet, Kees Cook, Greg Kroah-Hartman, Miguel Ojeda,
Shuah Khan
In-Reply-To: <CAHk-=whczwG=+-sAzoWoTY_VOwdFH3b5AkvQbgh+z98=p1iaXA@mail.gmail.com>
On Mon, Nov 10, 2025 at 11:36:00AM -0800, Linus Torvalds wrote:
>
> I really don't see what makes AI generated content so special.
The thread's become one of those jump-the-shark 'everybody + their dog
commenting' things, so risking adding more here, but...
As I said (or at least hope I did, or eventually did :) when I first raised
this on Sasha's original thread, in my MS proposal, and in review (which
Dave responded to very graciously - I think the doc is _mostly_ really
good) - I think LLMs really _are_ different in one important respect:
Submitter/maintainer asymmetry.
The issue is that people can generate sensible-looking series _EN MASSE_ that
now maintainers now HAVE to deal with.
That's the _BIG_ difference here.
With coccinelle etc. you need _some_ level of understanding of tooling
etc. to do it which acts as a barrier and maintiners submitter/maintiner
symmetry SOMEWHAT (with, err, at least one notable exception ;)
Now 'any idiot' can fire off hundreds of patches that look at a glance as
if they might have some validiity.
The asymmetry of this is VERY concerning.
I also hate that we have to think about it, but the second the press put
out 'the kernel accepts AI patches now!' - and trust me THEY WILL - we are
likely to see an influx like this that maintainers will have to deal with.
And much like the 'Linus doesn't scale' issue we hit some time ago, we
might hit a 'maintainers don't scale' issue here.
SO.
I think what we have to underline is:
1. Maintains MUST have the ability to JUST SAY NO, go away _en-masse_ to
regain symmetry on this.
It might throw out the baby with the bath water in some cases, but it may
be a price we have to pay to avoid disaster.
Rightly people don't like BLANKET NAKS. But I think we need to be very
clear that - in this case - you might very well get them so to avoid
unworkable asymmetry.
2. Those who submit patches MUST UNDERSTAND EVERY PART OF IT.
'that which can be proposed without understanding can be dismissed without
understanding'.
I think as long as we UNDERLINE these points I think we're good.
TL;DR: we won't take slop.
Otherwise, sure, plus ca change.
Cheers, Lorenzo
^ permalink raw reply
* Re: [RFC 0/2] Add AI coding assistant configuration to Linux kernel
From: Jarkko Sakkinen @ 2025-11-11 2:23 UTC (permalink / raw)
To: Sasha Levin
Cc: workflows, linux-doc, linux-kernel, rostedt, kees, konstantin,
corbet, josh
In-Reply-To: <20250725175358.1989323-1-sashal@kernel.org>
On Fri, Jul 25, 2025 at 01:53:56PM -0400, Sasha Levin wrote:
> This patch series adds unified configuration and documentation for AI
> coding assistants working with the Linux kernel codebase. As AI tools
> become increasingly common in software development, it's important to
> establish clear guidelines for their use in kernel development.
I sometimes use tools like sed (just to name one) to generate a patch
plus edits. I don't think we need contribution guidelines for sed, do
we? Equally we don't need contribution guidelines for AIs because:
1. AI is not a person.
2. AI has no resposibility.
3. AI has no needs.
Basic computer science beholds to truth that for any problem there is
infinite amount of computer programs to solve it. This makes any problem
we have a moving target constrained by various corner cases, people and
many other things.
If you want to use AI to generate code, it's obviously fine. I don't
mind and I don't care, and I don't see anything wrong in that.
But that is million miles away from being enough to be called as done.
Generation is about getting up on speed, and in the best case scenario
to the ballpark.
Please, let's keep this out of the kernel tree seriously.
BR, Jarkko
^ permalink raw reply
* Re: [PATCH] [v2] Documentation: Provide guidelines for tool-generated content
From: Theodore Ts'o @ 2025-11-10 23:16 UTC (permalink / raw)
To: Steven Rostedt
Cc: Linus Torvalds, H. Peter Anvin, Mike Rapoport, Laurent Pinchart,
Christian Brauner, Dave Hansen, Vlastimil Babka, linux-kernel,
workflows@vger.kernel.org, ksummit@lists.linux.dev, Dan Williams,
Sasha Levin, Jonathan Corbet, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Shuah Khan
In-Reply-To: <20251110145405.5bc87cc5@gandalf.local.home>
On Mon, Nov 10, 2025 at 02:54:05PM -0500, Steven Rostedt wrote:
> Probably no difference. I would guess the real liability is for those that
> use AI to submit patches. With the usual disclaimers of IANAL, I'm assuming
> that when you place your "Signed-off-by", you are stating that you have the
> right to submit this code. If it comes down that you did not have the right
> to submit the code, the original submitter is liable.
>
> I guess the question also is, is the maintainer that took that patch and
> added their SoB also liable?
ObDisclaimer: Although I have take one or two law classes at the MIT
Sloan School (e.g., "Law for the I/T Manager"), I am not a lawyer, and
more importantly, I am not *your* lawyer. So this is not legal
advice.
Maintainers are always assuming that code that has a Signed-Off-By is
code that the submitter has a right to submit. This is true before
AI, and it will be true today, after the advent of AI. If I receive a
patch from someone who works for Google, or Microoft, or Amazon, how
do I know that they haven't cut and pasted code from their compan's
internal proprieatry code base? I don't. I rely on the Signed-off-by
and the good faith of the code submitter, and if someone sends me code
that they aren't authorized, it is my personal belief that I wouldn't be
liable; only the submitter.
What is true for code written by human (who might or might not have
cut and pasted from their internal code search), it should just be as
true for AI-generated code.
In fact, from a strict legal liability perspective, I'd be happier not
knowing whether or not a particlar patch had some kind of LLM
involved. What I don't know, I can't *possibly* be held liable.
- Ted
^ permalink raw reply
* Re: [PATCH] [v2] Documentation: Provide guidelines for tool-generated content
From: James Bottomley @ 2025-11-10 22:07 UTC (permalink / raw)
To: Luck, Tony, Steven Rostedt
Cc: Linus Torvalds, H. Peter Anvin, Mike Rapoport, Laurent Pinchart,
Christian Brauner, Dave Hansen, Vlastimil Babka,
linux-kernel@vger.kernel.org, workflows@vger.kernel.org,
ksummit@lists.linux.dev, Williams, Dan J, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Shuah Khan
In-Reply-To: <SJ1PR11MB6083B928B445DF82EE5AE3EEFCCEA@SJ1PR11MB6083.namprd11.prod.outlook.com>
On Mon, 2025-11-10 at 21:52 +0000, Luck, Tony wrote:
> > I believe that's what is currently being argued in court. If AI is
> > trained on human content and prints out something based on it, is
> > it a non-human creation?
So far (Bartz v. Anthropic and Kadrey v. Meta) the decisions have been
that the output is transformative enough that that is, in fact, an
independent creation.
> > This isn't a case of a monkey taking a selfie, where the
> > content provider is clearly non-human. This is a machine that uses
> > human created content to derive new creations.
>
> If the output were deemed copyrightable, who should own that
> copyright?
>
> Option 1 is "The human that crafted the prompt to generate it"
This is possible, but so far hasn't been argued.
>
> Option 2 is "The corporation that spent vast resources to create that
> AI model"
This would require a change of law in the US to allow a non-human
content creator to hold copyright; absent that there's nothing
copyrightable the corporation can lay claim to (not that the AI
industry might not be motivated to seek this eventually if they have
trouble monetizing AI).
> Option 3 is "The owners of the copyrighted material used to train the
> AI".
This is the derivative of training argument which has so far failed.
Regards,
James
^ permalink raw reply
* RE: [PATCH] [v2] Documentation: Provide guidelines for tool-generated content
From: Luck, Tony @ 2025-11-10 21:52 UTC (permalink / raw)
To: Steven Rostedt, James Bottomley
Cc: Linus Torvalds, H. Peter Anvin, Mike Rapoport, Laurent Pinchart,
Christian Brauner, Dave Hansen, Vlastimil Babka,
linux-kernel@vger.kernel.org, workflows@vger.kernel.org,
ksummit@lists.linux.dev, Williams, Dan J, Theodore Ts'o,
Sasha Levin, Jonathan Corbet, Kees Cook, Greg Kroah-Hartman,
Miguel Ojeda, Shuah Khan
In-Reply-To: <20251110164225.4b343fe4@gandalf.local.home>
> I believe that's what is currently being argued in court. If AI is trained
> on human content and prints out something based on it, is it a non-human
> creation? This isn't a case of a monkey taking a selfie, where the content
> provider is clearly non-human. This is a machine that uses human created
> content to derive new creations.
If the output were deemed copyrightable, who should own that copyright?
Option 1 is "The human that crafted the prompt to generate it"
Option 2 is "The corporation that spent vast resources to create that AI model"
Option 3 is "The owners of the copyrighted material used to train the AI".
If a court ever must decide which to pick, it may well pick the answer requested
by the best funded legal team (which would be option 2).
-Tony
^ permalink raw reply
* Re: [PATCH] [v2] Documentation: Provide guidelines for tool-generated content
From: Steven Rostedt @ 2025-11-10 21:42 UTC (permalink / raw)
To: James Bottomley
Cc: Linus Torvalds, H. Peter Anvin, Mike Rapoport, Laurent Pinchart,
Christian Brauner, Dave Hansen, Vlastimil Babka, linux-kernel,
workflows@vger.kernel.org, ksummit@lists.linux.dev, Dan Williams,
Theodore Ts'o, Sasha Levin, Jonathan Corbet, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Shuah Khan
In-Reply-To: <21622a5393ef21413cae91d9c8ebbb8425d2c193.camel@HansenPartnership.com>
On Mon, 10 Nov 2025 16:21:30 -0500
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> As far as the copyright status of AI output in the US goes, as long as
> its not derivative of something, then it's a non-human creation and as
> such cannot be copyrighted at all, so it's equivalent to public domain.
I believe that's what is currently being argued in court. If AI is trained
on human content and prints out something based on it, is it a non-human
creation? This isn't a case of a monkey taking a selfie, where the content
provider is clearly non-human. This is a machine that uses human created
content to derive new creations.
-- Steve
^ permalink raw reply
* Re: [PATCH] [v2] Documentation: Provide guidelines for tool-generated content
From: James Bottomley @ 2025-11-10 21:21 UTC (permalink / raw)
To: Steven Rostedt, Linus Torvalds
Cc: H. Peter Anvin, Mike Rapoport, Laurent Pinchart,
Christian Brauner, Dave Hansen, Vlastimil Babka, linux-kernel,
workflows@vger.kernel.org, ksummit@lists.linux.dev, Dan Williams,
Theodore Ts'o, Sasha Levin, Jonathan Corbet, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Shuah Khan
In-Reply-To: <20251110145405.5bc87cc5@gandalf.local.home>
On Mon, 2025-11-10 at 14:54 -0500, Steven Rostedt wrote:
> On Mon, 10 Nov 2025 11:36:00 -0800
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> > What's the copyright difference between artificial intelligence and
> > good oldfashioned wetware that isn't documented by "I used this
> > tool and these sources".
>
> Probably no difference. I would guess the real liability is for those
> that use AI to submit patches. With the usual disclaimers of IANAL,
> I'm assuming that when you place your "Signed-off-by", you are
> stating that you have the right to submit this code. If it comes down
> that you did not have the right to submit the code, the original
> submitter is liable.
Liable for what? Signed-off-by is a representation by you that you
followed the DCO, nothing more:
https://developercertificate.org/
Liability arises when someone reasonably relies on that representation
for some purpose and remember most licences actually disclaim fitness
for a particular purpose in all situations (the no warranty clause), so
we have loads of protection from general "liability" fears.
> I guess the question also is, is the maintainer that took that patch
> and added their SoB also liable?
See above for liability. If you mean what representations does a
Maintainer give with a signoff, that's usually section (c):
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it
> If it is discovered that the AI tool was using source code that it
> wasn't supposed to be using, and then injected code that was pretty
> much verbatim to the original source, where it would be a copyright
> infringement, would the submitter of the patch be responsible? Would
> the maintainer?
>
> I guess this would be no different if the submitter saw some code
> from a proprietary project and cut and pasted it without
> understanding they were not allowed to, and submitted that.
Right, the situation is analagous. However, remember today there's no
legal case law that says a model's output is a derivative work of its
training (although there are still several cases ongoing).
> If the lawyers come back and say the onus is on the submitter and not
> the maintainer that the code being submitted is legal to be submitted
> under copyright law, then I'm perfectly fine in accepting any AI code
> (as long as the submitter can prove they understand that code and the
> code is clean).
Again, what do you mean by Liable? The representations in the DCO are
fairly clear and as long as you have a good faith basis for following
their requirements the chances are that even if things like CRA pierce
the licence no-warranty clauses you wouldn't end up on the hook for a
copyright violation committed by a downstream author.
Remember also that a big design of the signoff is that if someone does
do something wrong, their contributions can be quickly identified and
excised (which is probably why AI contributions should be tagged with
which AI they came from).
If you want more assurance, let's take the example of the 10 lines of
code SCO eventually decided had been cut and pasted from Unixware by a
SGI engineer. Their goal was to go after the shipper of the code with
the biggest pockets (IBM) they never made a case against the individual
engineer (probably mostly because the GPL no-warranty would make it
very hard to make the case and in minor part because the recovery would
be minimal)
> But until the lawyers state that explicitly, I can see why
> maintainers can be nervous about accepting AI generated code. Perhaps
> this transparency can make matters worse. As it can be argued that
> the maintainer knew it was a questionable AI that generated the code?
> (Like it would be if a maintainer knew the code being submitted was
> copied from a proprietary project).
There is so far no court case that AI output infringes copyright (there
are cases that have decided that AI training breached copyright
control, but none that that makes the output a derivative work of that
training), so that currently means that everyone can accept in good
faith that AI generated code is not infringing. Even if the copyright
lobby eventually wins a case on the derivative nature of the output,
that won't change your historical good faith basis for accepting code,
although it may mean the project needs to undertake an effort to excise
it.
As far as the copyright status of AI output in the US goes, as long as
its not derivative of something, then it's a non-human creation and as
such cannot be copyrighted at all, so it's equivalent to public domain.
Regards,
James
^ permalink raw reply
* Re: [PATCH] [v2] Documentation: Provide guidelines for tool-generated content
From: Steven Rostedt @ 2025-11-10 20:25 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: Linus Torvalds, H. Peter Anvin, Mike Rapoport, Laurent Pinchart,
Christian Brauner, Dave Hansen, Vlastimil Babka, linux-kernel,
workflows@vger.kernel.org, ksummit@lists.linux.dev, Dan Williams,
Theodore Ts'o, Sasha Levin, Jonathan Corbet, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Shuah Khan
In-Reply-To: <20251110-spiffy-intelligent-cockle-efde1e@lemur>
On Mon, 10 Nov 2025 15:00:54 -0500
Konstantin Ryabitsev <konstantin@linuxfoundation.org> wrote:
> On Mon, Nov 10, 2025 at 02:54:05PM -0500, Steven Rostedt wrote:
> > Probably no difference. I would guess the real liability is for those that
> > use AI to submit patches. With the usual disclaimers of IANAL, I'm assuming
> > that when you place your "Signed-off-by", you are stating that you have the
> > right to submit this code. If it comes down that you did not have the right
> > to submit the code, the original submitter is liable.
>
> And if the lawyers come back and say that the submitter is not liable, what's
> to prevent someone from copypasting actual copyrighted code from a proprietary
> source and adding a "Generated-by: Chat j'ai-pété" line to absolve themselves?
>
Wouldn't that be up to the courts? I shouldn't say "the lawyers come back
and say", it's more like "a court has ruled", and keeping to court
precedent, the lawyers would say "this is how it was ruled before". Of
course, today I'm not really sure how much "precedent" matters :-p
-- Steve
^ permalink raw reply
* Re: [PATCH] [v2] Documentation: Provide guidelines for tool-generated content
From: Konstantin Ryabitsev @ 2025-11-10 20:00 UTC (permalink / raw)
To: Steven Rostedt
Cc: Linus Torvalds, H. Peter Anvin, Mike Rapoport, Laurent Pinchart,
Christian Brauner, Dave Hansen, Vlastimil Babka, linux-kernel,
workflows@vger.kernel.org, ksummit@lists.linux.dev, Dan Williams,
Theodore Ts'o, Sasha Levin, Jonathan Corbet, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Shuah Khan
In-Reply-To: <20251110145405.5bc87cc5@gandalf.local.home>
On Mon, Nov 10, 2025 at 02:54:05PM -0500, Steven Rostedt wrote:
> Probably no difference. I would guess the real liability is for those that
> use AI to submit patches. With the usual disclaimers of IANAL, I'm assuming
> that when you place your "Signed-off-by", you are stating that you have the
> right to submit this code. If it comes down that you did not have the right
> to submit the code, the original submitter is liable.
And if the lawyers come back and say that the submitter is not liable, what's
to prevent someone from copypasting actual copyrighted code from a proprietary
source and adding a "Generated-by: Chat j'ai-pété" line to absolve themselves?
-K
^ permalink raw reply
* Re: [PATCH] [v2] Documentation: Provide guidelines for tool-generated content
From: Steven Rostedt @ 2025-11-10 19:54 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, Mike Rapoport, Laurent Pinchart,
Christian Brauner, Dave Hansen, Vlastimil Babka, linux-kernel,
workflows@vger.kernel.org, ksummit@lists.linux.dev, Dan Williams,
Theodore Ts'o, Sasha Levin, Jonathan Corbet, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Shuah Khan
In-Reply-To: <CAHk-=whczwG=+-sAzoWoTY_VOwdFH3b5AkvQbgh+z98=p1iaXA@mail.gmail.com>
On Mon, 10 Nov 2025 11:36:00 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> What's the copyright difference between artificial intelligence and
> good oldfashioned wetware that isn't documented by "I used this tool
> and these sources".
Probably no difference. I would guess the real liability is for those that
use AI to submit patches. With the usual disclaimers of IANAL, I'm assuming
that when you place your "Signed-off-by", you are stating that you have the
right to submit this code. If it comes down that you did not have the right
to submit the code, the original submitter is liable.
I guess the question also is, is the maintainer that took that patch and
added their SoB also liable?
If it is discovered that the AI tool was using source code that it wasn't
supposed to be using, and then injected code that was pretty much verbatim
to the original source, where it would be a copyright infringement, would
the submitter of the patch be responsible? Would the maintainer?
I guess this would be no different if the submitter saw some code from a
proprietary project and cut and pasted it without understanding they were
not allowed to, and submitted that.
If the lawyers come back and say the onus is on the submitter and not the
maintainer that the code being submitted is legal to be submitted under
copyright law, then I'm perfectly fine in accepting any AI code (as long as
the submitter can prove they understand that code and the code is clean).
But until the lawyers state that explicitly, I can see why maintainers can
be nervous about accepting AI generated code. Perhaps this transparency can
make matters worse. As it can be argued that the maintainer knew it was a
questionable AI that generated the code? (Like it would be if a maintainer
knew the code being submitted was copied from a proprietary project)
This is out of scope of the current patch, as the patch is about
transparency and not AI acceptance.
-- Steve
^ permalink raw reply
* Re: [PATCH] [v2] Documentation: Provide guidelines for tool-generated content
From: Linus Torvalds @ 2025-11-10 19:36 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Mike Rapoport, Laurent Pinchart, Christian Brauner, Dave Hansen,
Vlastimil Babka, linux-kernel, workflows@vger.kernel.org,
ksummit@lists.linux.dev, Steven Rostedt, Dan Williams,
Theodore Ts'o, Sasha Levin, Jonathan Corbet, Kees Cook,
Greg Kroah-Hartman, Miguel Ojeda, Shuah Khan
In-Reply-To: <A274AB1C-8B6B-4004-A2BC-D540260A5771@zytor.com>
On Mon, 10 Nov 2025 at 11:18, H. Peter Anvin <hpa@zytor.com> wrote:
>
> Copyright reasons, mainly.
I really don't see the argument.
The copyright issues are all true for all other code too. In fact, the
copyright issues are a thing whether tools were involved or not.
Copyright is *always* a thing.
We have a fair chunk of actual generated "new" code, whether it is the
millions of lines of register descriptions from hardware companies, or
it's the millions of lines of unicode data.
(Ok, the unicode data is just a few thousand lines, I exaggerate. But
we really do have several million lines AMD GPU headers that must have
been generated from hw descriptors, and there we didn't even ask for
the tool or the source, just for the usual copyright sign-off).
I really don't see what makes AI generated content so special.
Yes, I think you need to specify what the tool was and what the
conditions were for the change, but again - none of that is actually
new in ANY way.
This all feels like the usual AI hype-fest. Because THAT is the thing
that is truly special about AI. The hype, and the billions and
billions of dollars.
I claim that copyright is no different just because it was artificial.
What's the copyright difference between artificial intelligence and
good oldfashioned wetware that isn't documented by "I used this tool
and these sources".
It's just another tool, guys. It's one that makes some people a lot of
money, and yes, it will change society. But it's still just a tool.
Linus
^ permalink raw reply
* Re: [PATCH] [v2] Documentation: Provide guidelines for tool-generated content
From: H. Peter Anvin @ 2025-11-10 19:18 UTC (permalink / raw)
To: Linus Torvalds, Mike Rapoport
Cc: Laurent Pinchart, Christian Brauner, Dave Hansen, Vlastimil Babka,
linux-kernel, workflows@vger.kernel.org, ksummit@lists.linux.dev,
Steven Rostedt, Dan Williams, Theodore Ts'o, Sasha Levin,
Jonathan Corbet, Kees Cook, Greg Kroah-Hartman, Miguel Ojeda,
Shuah Khan
In-Reply-To: <CAHk-=wir-u3so=9NiFgG+bWfZHakc47iNy9vZXmSNWSZ+=Ue8g@mail.gmail.com>
On November 10, 2025 11:05:44 AM PST, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>On Mon, 10 Nov 2025 at 10:39, Mike Rapoport <rppt@kernel.org> wrote:
>>
>> The novelty here is that AI does not only transform the code, it can
>> generate it from scratch en masse.
>
>And why would that make any difference to the basic rules for us?
>
> "Plus ça change, plus c'est la même chose"
>
>It's a change in degree, not in any fundamentals.
>
> Linus
>
>
Copyright reasons, mainly.
^ permalink raw reply
* Re: [PATCH] [v2] Documentation: Provide guidelines for tool-generated content
From: Linus Torvalds @ 2025-11-10 19:05 UTC (permalink / raw)
To: Mike Rapoport
Cc: Laurent Pinchart, Christian Brauner, Dave Hansen, Vlastimil Babka,
linux-kernel, workflows@vger.kernel.org, ksummit@lists.linux.dev,
Steven Rostedt, Dan Williams, Theodore Ts'o, Sasha Levin,
Jonathan Corbet, Kees Cook, Greg Kroah-Hartman, Miguel Ojeda,
Shuah Khan
In-Reply-To: <aRIxYkjX7EzalSoI@kernel.org>
On Mon, 10 Nov 2025 at 10:39, Mike Rapoport <rppt@kernel.org> wrote:
>
> The novelty here is that AI does not only transform the code, it can
> generate it from scratch en masse.
And why would that make any difference to the basic rules for us?
"Plus ça change, plus c'est la même chose"
It's a change in degree, not in any fundamentals.
Linus
^ 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