* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Dan Carpenter @ 2026-01-12 19:02 UTC (permalink / raw)
To: James Bottomley
Cc: Matthew Wilcox, Serge E. Hallyn, Lorenzo Stoakes, Liam R. Howlett,
Jens Axboe, Dave Hansen, Dave Hansen, 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: <39da84e891a8ccd4a17115ce6a399c2f6498e78f.camel@HansenPartnership.com>
On Sat, Jan 10, 2026 at 11:02:19AM -0500, James Bottomley wrote:
> On Sat, 2026-01-10 at 15:52 +0000, Matthew Wilcox wrote:
> > On Sat, Jan 10, 2026 at 09:25:36AM -0600, Serge E. Hallyn wrote:
> > > I just don't think the word "slop" should be used, because while it
> > > may be very clear to you, and may be clearly defined in some
> > > communities, me, I'm just guessing what you mean by it.
> >
> > https://www.merriam-webster.com/wordplay/word-of-the-year
>
> Just because it's the word of the year this year doesn't mean people
> will remember what it means even after a few years. "Rawdog" was the
> OED word of the year in 2024 ... that's losing its resonance and who of
> the under 30 crowd knows what the 2000 word of the year "chad" means?
> The point of the formulation I proposed (without mentioning slop) was
> to be generic and retain its meaning over time.
Slop means you produced the patches in such quantity that you don't have
time to review the output before sending it. This isn't a totally new
thing, people have used clang-format to reformat a whole driver and it's
clear they didn't look at the output.
Even for bug reports, the truth is that no one reads mass bug reports.
I occasionally send mass bug reports if I create a new warning. No one
ever reads them.
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Dave Hansen @ 2026-01-12 15:06 UTC (permalink / raw)
To: Lorenzo Stoakes, Steven Rostedt
Cc: Dan Carpenter, Dave Hansen, James Bottomley, 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, Jens Axboe
In-Reply-To: <3ef67380-bc8c-42c6-a5f8-416440e4c445@lucifer.local>
On 1/9/26 07:48, Lorenzo Stoakes wrote:
>>>>> +If tools permit you to generate series automatically, expect
>>>>> +additional scrutiny in proportion to how much of it was generated.
>>>>> +
>>>>> +As with the output of any tooling, the result maybe incorrect or
>>>>> +inappropriate, so you are expected to understand and to be able to defend
>>>>> +everything you submit. If you are unable to do so, then don't submit the
>>>>> +resulting changes.
>>>>> +
>>>>> +If you do so anyway, maintainers are entitled to reject your series without
>>>>> +detailed review.
>> I like it.
> Hmm, you like my version but then below argue against every point I make in
> favour of it? I'm confused?
>
> Did you mean to say you liked a suggested other revision or... really this
> one? 🙂
>
> If so and Dave likes it too then LGTM, pending any Linus/other veto.
Look good to me too!
I'll try to get a v5 out with this later toady.
^ permalink raw reply
* [PATCH v2] Documentation: Fix typos and grammatical errors
From: Nauman Sabir @ 2026-01-12 9:16 UTC (permalink / raw)
To: Jonathan Corbet, linux-doc
Cc: Nauman Sabir, Tejun Heo, Johannes Weiner, Michal Koutný,
Chun-Kuang Hu, Philipp Zabel, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Gao Xiang, Chao Yu, Yue Hu,
Jeffle Xu, Sandeep Dhavale, Hongbo Li, Chunhai Guo,
Nathan Chancellor, Nicolas Schier, Mauro Carvalho Chehab,
Matthias Brugger, AngeloGioacchino Del Regno, Jitao shi,
linux-kernel, cgroups, dri-devel, linux-mediatek, devicetree,
linux-erofs, linux-kbuild, workflows, linux-media,
linux-arm-kernel
Fix various typos and grammatical errors across multiple documentation
files to improve clarity and consistency.
Changes include:
- Fix missing preposition 'in' in process/changes.rst
- Correct 'result by' to 'result from' in admin-guide/README.rst
- Fix 'before hand' to 'beforehand' (3 instances) in cgroup-v1/hugetlb.rst
- Correct 'allows to limit' to 'allows limiting' in cgroup-v1/hugetlb.rst,
cgroup-v2.rst, and kconfig-language.rst
- Fix 'needs precisely know' to 'needs to precisely know' in
cgroup-v1/hugetlb.rst
- Correct 'overcommited' to 'overcommitted' in cgroup-v1/hugetlb.rst
- Fix subject-verb agreement: 'never causes' to 'never cause' (2 instances)
in cgroup-v1/hugetlb.rst
- Fix subject-verb agreement: 'there is enough' to 'there are enough' in
cgroup-v1/hugetlb.rst
- Remove incorrect plural from uncountable nouns: 'metadatas' to 'metadata'
in filesystems/erofs.rst, and 'hardwares' to 'hardware' in
devicetree/bindings/.../mediatek,dp.yaml, userspace-api/.../legacy_dvb_audio.rst,
and scsi/ChangeLog.sym53c8xx
Note: British spelling 'recognised' retained per maintainer feedback.
These corrections improve the overall quality and readability of the
kernel documentation.
Signed-off-by: Nauman Sabir <officialnaumansabir@gmail.com>
---
Documentation/admin-guide/README.rst | 2 +-
.../admin-guide/cgroup-v1/hugetlb.rst | 18 +++++++++---------
Documentation/admin-guide/cgroup-v2.rst | 2 +-
.../bindings/display/mediatek/mediatek,dp.yaml | 2 +-
Documentation/filesystems/erofs.rst | 2 +-
Documentation/kbuild/kconfig-language.rst | 2 +-
Documentation/process/changes.rst | 2 +-
Documentation/scsi/ChangeLog.sym53c8xx | 2 +-
.../media/dvb/legacy_dvb_audio.rst | 2 +-
9 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/Documentation/admin-guide/README.rst b/Documentation/admin-guide/README.rst
index 05301f03b..77fec1de6 100644
--- a/Documentation/admin-guide/README.rst
+++ b/Documentation/admin-guide/README.rst
@@ -53,7 +53,7 @@ Documentation
these typically contain kernel-specific installation notes for some
drivers for example. Please read the
:ref:`Documentation/process/changes.rst <changes>` file, as it
- contains information about the problems, which may result by upgrading
+ contains information about the problems which may result from upgrading
your kernel.
Installing the kernel source
diff --git a/Documentation/admin-guide/cgroup-v1/hugetlb.rst b/Documentation/admin-guide/cgroup-v1/hugetlb.rst
index 493a8e386..b5f3873b7 100644
--- a/Documentation/admin-guide/cgroup-v1/hugetlb.rst
+++ b/Documentation/admin-guide/cgroup-v1/hugetlb.rst
@@ -77,7 +77,7 @@ control group and enforces the limit during page fault. Since HugeTLB
doesn't support page reclaim, enforcing the limit at page fault time implies
that, the application will get SIGBUS signal if it tries to fault in HugeTLB
pages beyond its limit. Therefore the application needs to know exactly how many
-HugeTLB pages it uses before hand, and the sysadmin needs to make sure that
+HugeTLB pages it uses beforehand, and the sysadmin needs to make sure that
there are enough available on the machine for all the users to avoid processes
getting SIGBUS.
@@ -91,23 +91,23 @@ getting SIGBUS.
hugetlb.<hugepagesize>.rsvd.usage_in_bytes
hugetlb.<hugepagesize>.rsvd.failcnt
-The HugeTLB controller allows to limit the HugeTLB reservations per control
+The HugeTLB controller allows limiting the HugeTLB reservations per control
group and enforces the controller limit at reservation time and at the fault of
HugeTLB memory for which no reservation exists. Since reservation limits are
-enforced at reservation time (on mmap or shget), reservation limits never causes
-the application to get SIGBUS signal if the memory was reserved before hand. For
+enforced at reservation time (on mmap or shget), reservation limits never cause
+the application to get SIGBUS signal if the memory was reserved beforehand. For
MAP_NORESERVE allocations, the reservation limit behaves the same as the fault
limit, enforcing memory usage at fault time and causing the application to
receive a SIGBUS if it's crossing its limit.
Reservation limits are superior to page fault limits described above, since
reservation limits are enforced at reservation time (on mmap or shget), and
-never causes the application to get SIGBUS signal if the memory was reserved
-before hand. This allows for easier fallback to alternatives such as
+never cause the application to get SIGBUS signal if the memory was reserved
+beforehand. This allows for easier fallback to alternatives such as
non-HugeTLB memory for example. In the case of page fault accounting, it's very
-hard to avoid processes getting SIGBUS since the sysadmin needs precisely know
-the HugeTLB usage of all the tasks in the system and make sure there is enough
-pages to satisfy all requests. Avoiding tasks getting SIGBUS on overcommited
+hard to avoid processes getting SIGBUS since the sysadmin needs to precisely know
+the HugeTLB usage of all the tasks in the system and make sure there are enough
+pages to satisfy all requests. Avoiding tasks getting SIGBUS on overcommitted
systems is practically impossible with page fault accounting.
diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst
index 7f5b59d95..098d6831b 100644
--- a/Documentation/admin-guide/cgroup-v2.rst
+++ b/Documentation/admin-guide/cgroup-v2.rst
@@ -2816,7 +2816,7 @@ DMEM Interface Files
HugeTLB
-------
-The HugeTLB controller allows to limit the HugeTLB usage per control group and
+The HugeTLB controller allows limiting the HugeTLB usage per control group and
enforces the controller limit during page fault.
HugeTLB Interface Files
diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml
index 274f59080..8f4bd9fb5 100644
--- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml
+++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dp.yaml
@@ -11,7 +11,7 @@ maintainers:
- Jitao shi <jitao.shi@mediatek.com>
description: |
- MediaTek DP and eDP are different hardwares and there are some features
+ MediaTek DP and eDP are different hardware and there are some features
which are not supported for eDP. For example, audio is not supported for
eDP. Therefore, we need to use two different compatibles to describe them.
In addition, We just need to enable the power domain of DP, so the clock
diff --git a/Documentation/filesystems/erofs.rst b/Documentation/filesystems/erofs.rst
index 08194f194..e61db115e 100644
--- a/Documentation/filesystems/erofs.rst
+++ b/Documentation/filesystems/erofs.rst
@@ -154,7 +154,7 @@ to be as simple as possible::
0 +1K
All data areas should be aligned with the block size, but metadata areas
-may not. All metadatas can be now observed in two different spaces (views):
+may not. All metadata can be now observed in two different spaces (views):
1. Inode metadata space
diff --git a/Documentation/kbuild/kconfig-language.rst b/Documentation/kbuild/kconfig-language.rst
index abce88f15..7067ec3f0 100644
--- a/Documentation/kbuild/kconfig-language.rst
+++ b/Documentation/kbuild/kconfig-language.rst
@@ -216,7 +216,7 @@ applicable everywhere (see syntax).
- numerical ranges: "range" <symbol> <symbol> ["if" <expr>]
- This allows to limit the range of possible input values for int
+ This allows limiting the range of possible input values for int
and hex symbols. The user can only input a value which is larger than
or equal to the first symbol and smaller than or equal to the second
symbol.
diff --git a/Documentation/process/changes.rst b/Documentation/process/changes.rst
index 62951cdb1..0cf97dbab 100644
--- a/Documentation/process/changes.rst
+++ b/Documentation/process/changes.rst
@@ -218,7 +218,7 @@ DevFS has been obsoleted in favour of udev
Linux documentation for functions is transitioning to inline
documentation via specially-formatted comments near their
definitions in the source. These comments can be combined with ReST
-files the Documentation/ directory to make enriched documentation, which can
+files in the Documentation/ directory to make enriched documentation, which can
then be converted to PostScript, HTML, LaTex, ePUB and PDF files.
In order to convert from ReST format to a format of your choice, you'll need
Sphinx.
diff --git a/Documentation/scsi/ChangeLog.sym53c8xx b/Documentation/scsi/ChangeLog.sym53c8xx
index 3435227a2..6bca91e03 100644
--- a/Documentation/scsi/ChangeLog.sym53c8xx
+++ b/Documentation/scsi/ChangeLog.sym53c8xx
@@ -3,7 +3,7 @@ Sat May 12 12:00 2001 Gerard Roudier (groudier@club-internet.fr)
- Ensure LEDC bit in GPCNTL is cleared when reading the NVRAM.
Fix sent by Stig Telfer <stig@api-networks.com>.
- Backport from SYM-2 the work-around that allows to support
- hardwares that fail PCI parity checking.
+ hardware that fails PCI parity checking.
- Check that we received at least 8 bytes of INQUIRY response
for byte 7, that contains device capabilities, to be valid.
- Define scsi_set_pci_device() as nil for kernel < 2.4.4.
diff --git a/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst b/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst
index 81b762ef1..99ffda355 100644
--- a/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst
+++ b/Documentation/userspace-api/media/dvb/legacy_dvb_audio.rst
@@ -444,7 +444,7 @@ Description
~~~~~~~~~~~
A call to `AUDIO_GET_CAPABILITIES`_ returns an unsigned integer with the
-following bits set according to the hardwares capabilities.
+following bits set according to the hardware's capabilities.
-----
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v2] LICENSES: Explicitly allow SPDX-FileCopyrightText
From: Laurent Pinchart @ 2026-01-11 16:15 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Thomas Gleixner, Greg Kroah-Hartman, Jonathan Corbet,
Andy Whitcroft, Joe Perches, Dwaipayan Ray, Lukas Bulwahn,
linux-spdx, workflows, linux-doc, linux-kernel
In-Reply-To: <20260111160750.17569-2-krzysztof.kozlowski@oss.qualcomm.com>
On Sun, Jan 11, 2026 at 05:07:51PM +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.
>
> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Cc: Joe Perches <joe@perches.com>
> 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.
My only concern is that we're endorsing two different ways to express
copyright information. That usually leads to different subsystem setting
different rules, and worse, to people sending conversion patches.
I don't mind how copyright information is expressed. The
SPDX-FileCopyrightText tag has the advantage of being machine-parseable,
even if the value of the extracted information is somehow dubious from a
legal point of view. Other than than, both ways seem fine. I have a
slight personal preference for standardizing things, but the SPDX
specification doesn't mandate a particular formatting of the
SPDX-FileCopyrightText value, so there will always be different styles
anyway.
> Changes in v2:
> 1. Doc adjustments based on feedback from Greg and Laurent.
> 2. "unused" -> "unsupported"
> 3. Drop redundant blank line
> ---
> Documentation/process/license-rules.rst | 7 +++++--
> scripts/checkpatch.pl | 8 ++++++++
> 2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/process/license-rules.rst b/Documentation/process/license-rules.rst
> index 59a7832df7d0..5cc58168e3d9 100644
> --- a/Documentation/process/license-rules.rst
> +++ b/Documentation/process/license-rules.rst
> @@ -63,8 +63,11 @@ License identifier syntax
> The SPDX license identifier in kernel files shall be added at the first
> possible line in a file which can contain a comment. For the majority
> of files this is the first line, except for scripts which require the
> - '#!PATH_TO_INTERPRETER' in the first line. For those scripts the SPDX
> - identifier goes into the second line.
> + '#!PATH_TO_INTERPRETER' in the first line. For those scripts, the SPDX
> + license identifier goes into the second line.
> +
> + The license identifier line can then be followed by one of multiple
s/of multiple/or multiple/
> + SPDX-FileCopyrightText lines if desired.
>
> |
>
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> index 362a8d1cd327..cc2a5882fef8 100755
> --- a/scripts/checkpatch.pl
> +++ b/scripts/checkpatch.pl
> @@ -3844,6 +3844,14 @@ sub process {
> "Misplaced SPDX-License-Identifier tag - use line $checklicenseline instead\n" . $herecurr);
> }
>
> +# check for unsupported 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:
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2] LICENSES: Explicitly allow SPDX-FileCopyrightText
From: Krzysztof Kozlowski @ 2026-01-11 16:07 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, Laurent Pinchart
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.
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Joe Perches <joe@perches.com>
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.
Changes in v2:
1. Doc adjustments based on feedback from Greg and Laurent.
2. "unused" -> "unsupported"
3. Drop redundant blank line
---
Documentation/process/license-rules.rst | 7 +++++--
scripts/checkpatch.pl | 8 ++++++++
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/Documentation/process/license-rules.rst b/Documentation/process/license-rules.rst
index 59a7832df7d0..5cc58168e3d9 100644
--- a/Documentation/process/license-rules.rst
+++ b/Documentation/process/license-rules.rst
@@ -63,8 +63,11 @@ License identifier syntax
The SPDX license identifier in kernel files shall be added at the first
possible line in a file which can contain a comment. For the majority
of files this is the first line, except for scripts which require the
- '#!PATH_TO_INTERPRETER' in the first line. For those scripts the SPDX
- identifier goes into the second line.
+ '#!PATH_TO_INTERPRETER' in the first line. For those scripts, the SPDX
+ license identifier goes into the second line.
+
+ The license identifier line can then be followed by one of multiple
+ SPDX-FileCopyrightText lines if desired.
|
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 362a8d1cd327..cc2a5882fef8 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3844,6 +3844,14 @@ sub process {
"Misplaced SPDX-License-Identifier tag - use line $checklicenseline instead\n" . $herecurr);
}
+# check for unsupported 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: Steven Rostedt @ 2026-01-10 16:07 UTC (permalink / raw)
To: James Bottomley
Cc: Matthew Wilcox, Serge E. Hallyn, Lorenzo Stoakes, Dan Carpenter,
Liam R. Howlett, Jens Axboe, Dave Hansen, 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: <39da84e891a8ccd4a17115ce6a399c2f6498e78f.camel@HansenPartnership.com>
On Sat, 10 Jan 2026 11:02:19 -0500
James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
> On Sat, 2026-01-10 at 15:52 +0000, Matthew Wilcox wrote:
> > On Sat, Jan 10, 2026 at 09:25:36AM -0600, Serge E. Hallyn wrote:
> > > I just don't think the word "slop" should be used, because while it
> > > may be very clear to you, and may be clearly defined in some
> > > communities, me, I'm just guessing what you mean by it.
> >
> > https://www.merriam-webster.com/wordplay/word-of-the-year
>
> Just because it's the word of the year this year doesn't mean people
> will remember what it means even after a few years. "Rawdog" was the
> OED word of the year in 2024 ... that's losing its resonance and who of
> the under 30 crowd knows what the 2000 word of the year "chad" means?
> The point of the formulation I proposed (without mentioning slop) was
> to be generic and retain its meaning over time.
I agree with James here. "Slop" may be well known today, but it is
still a slang word. It may easily lose its meaning in the future, and I
don't think "slang" words should be used in the document.
-- Steve
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: James Bottomley @ 2026-01-10 16:02 UTC (permalink / raw)
To: Matthew Wilcox, Serge E. Hallyn
Cc: Lorenzo Stoakes, Dan Carpenter, Liam R. Howlett, Jens Axboe,
Dave Hansen, Dave Hansen, 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: <aWJ1ufun16-5EEkb@casper.infradead.org>
On Sat, 2026-01-10 at 15:52 +0000, Matthew Wilcox wrote:
> On Sat, Jan 10, 2026 at 09:25:36AM -0600, Serge E. Hallyn wrote:
> > I just don't think the word "slop" should be used, because while it
> > may be very clear to you, and may be clearly defined in some
> > communities, me, I'm just guessing what you mean by it.
>
> https://www.merriam-webster.com/wordplay/word-of-the-year
Just because it's the word of the year this year doesn't mean people
will remember what it means even after a few years. "Rawdog" was the
OED word of the year in 2024 ... that's losing its resonance and who of
the under 30 crowd knows what the 2000 word of the year "chad" means?
The point of the formulation I proposed (without mentioning slop) was
to be generic and retain its meaning over time.
Regards,
James
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Matthew Wilcox @ 2026-01-10 15:52 UTC (permalink / raw)
To: Serge E. Hallyn
Cc: Lorenzo Stoakes, Dan Carpenter, Liam R. Howlett, Jens Axboe,
Dave Hansen, James Bottomley, Dave Hansen, 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: <aWJvcPeV5ziCt5Du@mail.hallyn.com>
On Sat, Jan 10, 2026 at 09:25:36AM -0600, Serge E. Hallyn wrote:
> I just don't think the word "slop" should be used, because while it may
> be very clear to you, and may be clearly defined in some communities, me,
> I'm just guessing what you mean by it.
https://www.merriam-webster.com/wordplay/word-of-the-year
Picked up by AP and widely reported on by news organisations, eg:
https://www.cbc.ca/news/entertainment/slop-word-of-the-year-9.7015916
https://www.pbs.org/newshour/nation/merriam-websters-word-of-the-year-for-2025-is-ais-slop
https://arstechnica.com/ai/2025/12/merriam-webster-crowns-slop-word-of-the-year-as-ai-content-floods-internet/
It's widely known.
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Serge E. Hallyn @ 2026-01-10 15:25 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Dan Carpenter, Liam R. Howlett, Jens Axboe, Dave Hansen,
James Bottomley, Dave Hansen, 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: <0b9a8f99-5cc4-40e8-a0e6-4887d1e1a796@lucifer.local>
On Fri, Jan 09, 2026 at 07:54:31AM +0000, Lorenzo Stoakes wrote:
> On Fri, Jan 09, 2026 at 08:29:58AM +0300, Dan Carpenter wrote:
> > On Thu, Jan 08, 2026 at 04:04:39PM -0500, Liam R. Howlett wrote:
> > > * Jens Axboe <axboe@kernel.dk> [260108 15:54]:
> > > > On 1/8/26 12:23 PM, Lorenzo Stoakes wrote:
> > > > >> @@ -95,3 +95,8 @@ choose how they handle the contribution. For example, they might:
> > > > >> - 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.
> > > > >> +
> > > > >> +Finally, always be prepared for tooling that produces incorrect or
> > > > >> +inappropriate content. Make sure you understand and to be able to
> > > > >> +defend everything you submit. If you are unable to do so, maintainers
> > > > >> +may choose to reject your series outright.
> > > > >>
> > > > >
> > > > > I feel like this formulation waters it down so much as to lose the emphasis
> > > > > which was the entire point of it.
> > > > >
> > > > > I'm also not sure why we're losing the scrutiny part?
> > > > >
> > > > > Something like:
> > > > >
> > > > > +If tools permit you to generate series entirely automatically, expect
> > > > > +additional scrutiny.
> > > > > +
> > > > > +As with the output of any tooling, the result maybe incorrect or
> > > > > +inappropriate, so you are expected to understand and to be able to defend
> > > > > +everything you submit. If you are unable to do so, maintainers may choose
> > > > > +to reject your series outright.
> > > >
> > > > Eh, why not some variant of:
> > > >
> > > > "If you are unable to do so, then don't submit the resulting changes."
> > > >
> > > > Talking only for myself, I have ZERO interest in receiving code from
> > > > someone that doesn't even understand what it does. And it'd be better to
> > > > NOT waste my or anyone elses time if that's the level of the submission.
> > >
> > > Yes, agreed.
> > >
> >
> > Yeah. Me too.
> >
> > > If I cannot understand it and the author is clueless about the patch,
> > > then I'm going to be way more grumpy than the wording of that statement.
> > >
> > > I'd assume the submitter would just get the ai to answer it anyways
> > > since that's fitting with the level of the submission.
> >
> > Yes. That has happened to me. I asked the submitter how do you know
> > this is true? And the v2 had a long AI generated explanation which quoted
> > a spec from an AI hallucination.
> >
> > I like Dave's document but the first paragraph should be to not send AI
> > slop.
>
> This is the entire point of my push back here :)
>
> I'd prefer us to be truly emphatic with a 'NO SLOP PLEASE' as the opener and
> using that term, but I'm compromising because... well you saw Linus's position
> right?
I just don't think the word "slop" should be used, because while it may
be very clear to you, and may be clearly defined in some communities, me,
I'm just guessing what you mean by it.
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Steven Rostedt @ 2026-01-09 19:08 UTC (permalink / raw)
To: Andrew Morton
Cc: Dan Carpenter, Lorenzo Stoakes, Dave Hansen, Dave Hansen,
James Bottomley, 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, Jens Axboe
In-Reply-To: <20260109103435.cb555ad5374a50db413e3861@linux-foundation.org>
On Fri, 9 Jan 2026 10:34:35 -0800
Andrew Morton <akpm@linux-foundation.org> wrote:
> As we work through these issues, please let's not accidentally do
> anything which impedes our ability to receive AI-generated bug reports.
> If that means having to deal with poor fixes for those bugs then so be
> it - the benefit of the bug report outweighs the cost of discarding the
> purported fix.
I agree with this statement. I just said that I find AI a much better bug
finder than code creator:
https://lore.kernel.org/all/20260109111929.2010949e@gandalf.local.home/
-- Steve
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Andrew Morton @ 2026-01-09 18:34 UTC (permalink / raw)
To: Dan Carpenter
Cc: Lorenzo Stoakes, Steven Rostedt, Dave Hansen, Dave Hansen,
James Bottomley, 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, Jens Axboe
In-Reply-To: <aWDf1zlLTKmw9xnq@stanley.mountain>
Dan, thanks for taking care of this.
My overall not-strongly-held take is that we shouldn't try to be overly
proscriptive at this stage. Wait and see if a problematic pattern
emerges and then deal with it.
But my main reason for weighing in: I haven't yet seen evidence that
the LLMs produce useful kernel changes, but AI is looking to be useful
at finding bugs.
If an AI-generated bug report comes in the form of a purported code fix
then it's "thanks for the bug report", delete the email then get in
and fix the issue in our usual way.
As we work through these issues, please let's not accidentally do
anything which impedes our ability to receive AI-generated bug reports.
If that means having to deal with poor fixes for those bugs then so be
it - the benefit of the bug report outweighs the cost of discarding the
purported fix.
^ permalink raw reply
* Re: [PATCH v6 4/5] slab: Introduce kmalloc_flex() and family
From: Vlastimil Babka @ 2026-01-09 17:12 UTC (permalink / raw)
To: Kees Cook
Cc: Jonathan Corbet, Andrew Morton, Christoph Lameter, David Rientjes,
Roman Gushchin, Harry Yoo, Gustavo A. R. Silva, workflows,
linux-doc, linux-mm, linux-hardening, Linus Torvalds,
Randy Dunlap, Miguel Ojeda, Przemek Kitszel, Matthew Wilcox,
John Hubbard, Joe Perches, Christoph Lameter, Marco Elver,
Vegard Nossum, Pekka Enberg, Joonsoo Kim, Bill Wendling,
Justin Stitt, Jann Horn, Greg Kroah-Hartman, Sasha Levin,
Nathan Chancellor, Peter Zijlstra, Nick Desaulniers,
Jakub Kicinski, Yafang Shao, Tony Ambardar, Alexander Lobakin,
Jan Hendrik Farr, Alexander Potapenko, linux-kernel, llvm
In-Reply-To: <20251203233036.3212363-4-kees@kernel.org>
On 12/4/25 00:30, Kees Cook wrote:
> As done for kmalloc_obj*(), introduce a type-aware allocator for flexible
> arrays, which may also have "counted_by" annotations:
>
> ptr = kmalloc(struct_size(ptr, flex_member, count), gfp);
>
> becomes:
>
> ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
>
> The internal use of __flex_counter() allows for automatically setting
> the counter member of a struct's flexible array member when it has
> been annotated with __counted_by(), avoiding any missed early size
> initializations while __counted_by() annotations are added to the
> kernel. Additionally, this also checks for "too large" allocations based
> on the type size of the counter variable. For example:
>
> if (count > type_max(ptr->flex_counter))
> fail...;
> size = struct_size(ptr, flex_member, count);
> ptr = kmalloc(size, gfp);
> ptr->flex_counter = count;
>
> becomes (n.b. unchanged from earlier example):
>
> ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
> ptr->flex_count = count;
>
> Note that manual initialization of the flexible array counter is still
> required (at some point) after allocation as not all compiler versions
> support the __counted_by annotation yet. But doing it internally makes
> sure they cannot be missed when __counted_by _is_ available, meaning
> that the bounds checker will not trip due to the lack of "early enough"
> initializations that used to work before enabling the stricter bounds
> checking. For example:
>
> ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
> fill(ptr->flex, count);
> ptr->flex_count = count;
>
> This works correctly before adding a __counted_by annotation (since
> nothing is checking ptr->flex accesses against ptr->flex_count). After
> adding the annotation, the bounds sanitizer would trip during fill()
> because ptr->flex_count wasn't set yet. But with kmalloc_flex() setting
> ptr->flex_count internally at allocation time, the existing code works
> without needing to move the ptr->flex_count assignment before the call
> to fill(). (This has been a stumbling block for __counted_by adoption.)
>
> Signed-off-by: Kees Cook <kees@kernel.org>
Acked-by: Vlastimil Babka <vbabka@suse.cz>
> ---
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: Vlastimil Babka <vbabka@suse.cz>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Christoph Lameter <cl@gentwo.org>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Roman Gushchin <roman.gushchin@linux.dev>
> Cc: Harry Yoo <harry.yoo@oracle.com>
> Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
> Cc: <workflows@vger.kernel.org>
> Cc: <linux-doc@vger.kernel.org>
> Cc: <linux-mm@kvack.org>
> Cc: <linux-hardening@vger.kernel.org>
> ---
> Documentation/process/deprecated.rst | 7 ++++
> include/linux/slab.h | 48 ++++++++++++++++++++++++++++
> 2 files changed, 55 insertions(+)
>
> diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst
> index 91c628fa2d59..fed56864d036 100644
> --- a/Documentation/process/deprecated.rst
> +++ b/Documentation/process/deprecated.rst
> @@ -387,6 +387,7 @@ allocations. For example, these open coded assignments::
> ptr = kzalloc(sizeof(*ptr), gfp);
> ptr = kmalloc_array(count, sizeof(*ptr), gfp);
> ptr = kcalloc(count, sizeof(*ptr), gfp);
> + ptr = kmalloc(struct_size(ptr, flex_member, count), gfp);
> ptr = kmalloc(sizeof(struct foo, gfp);
>
> become, respectively::
> @@ -395,4 +396,10 @@ become, respectively::
> ptr = kzalloc_obj(*ptr, gfp);
> ptr = kmalloc_objs(*ptr, count, gfp);
> ptr = kzalloc_objs(*ptr, count, gfp);
> + ptr = kmalloc_flex(*ptr, flex_member, count, gfp);
> __auto_type ptr = kmalloc_obj(struct foo, gfp);
> +
> +If `ptr->flex_member` is annotated with __counted_by(), the allocation
> +will automatically fail if `count` is larger than the maximum
> +representable value that can be stored in the counter member associated
> +with `flex_member`.
> diff --git a/include/linux/slab.h b/include/linux/slab.h
> index 726457daedbd..2656ea610b68 100644
> --- a/include/linux/slab.h
> +++ b/include/linux/slab.h
> @@ -982,6 +982,33 @@ void *kmalloc_nolock_noprof(size_t size, gfp_t gfp_flags, int node);
> (TYPE *)KMALLOC(__obj_size, GFP); \
> })
>
> +/**
> + * __alloc_flex - Allocate an object that has a trailing flexible array
> + * @KMALLOC: kmalloc wrapper function to use for allocation.
> + * @GFP: GFP flags for the allocation.
> + * @TYPE: type of structure to allocate space for.
> + * @FAM: The name of the flexible array member of @TYPE structure.
> + * @COUNT: how many @FAM elements to allocate space for.
> + *
> + * Returns: Newly allocated pointer to @TYPE with @COUNT-many trailing
> + * @FAM elements, or NULL on failure or if @COUNT cannot be represented
> + * by the member of @TYPE that counts the @FAM elements (annotated via
> + * __counted_by()).
> + */
> +#define __alloc_flex(KMALLOC, GFP, TYPE, FAM, COUNT) \
> +({ \
> + const size_t __count = (COUNT); \
> + const size_t __obj_size = struct_size_t(TYPE, FAM, __count); \
> + TYPE *__obj_ptr; \
> + if (WARN_ON_ONCE(overflows_flex_counter_type(TYPE, FAM, __count))) \
> + __obj_ptr = NULL; \
> + else \
> + __obj_ptr = KMALLOC(__obj_size, GFP); \
> + if (__obj_ptr) \
> + __set_flex_counter(__obj_ptr->FAM, __count); \
> + __obj_ptr; \
> +})
> +
> /**
> * kmalloc_obj - Allocate a single instance of the given type
> * @VAR_OR_TYPE: Variable or type to allocate.
> @@ -1005,23 +1032,44 @@ void *kmalloc_nolock_noprof(size_t size, gfp_t gfp_flags, int node);
> #define kmalloc_objs(VAR_OR_TYPE, COUNT, GFP) \
> __alloc_objs(kmalloc, GFP, typeof(VAR_OR_TYPE), COUNT)
>
> +/**
> + * kmalloc_flex - Allocate a single instance of the given flexible structure
> + * @VAR_OR_TYPE: Variable or type to allocate (with its flex array).
> + * @FAM: The name of the flexible array member of the structure.
> + * @COUNT: How many flexible array member elements are desired.
> + * @GFP: GFP flags for the allocation.
> + *
> + * Returns: newly allocated pointer to @VAR_OR_TYPE on success, NULL on
> + * failure. If @FAM has been annotated with __counted_by(), the allocation
> + * will immediately fail if @COUNT is larger than what the type of the
> + * struct's counter variable can represent.
> + */
> +#define kmalloc_flex(VAR_OR_TYPE, FAM, COUNT, GFP) \
> + __alloc_flex(kmalloc, GFP, typeof(VAR_OR_TYPE), FAM, COUNT)
> +
> /* All kzalloc aliases for kmalloc_(obj|objs|flex). */
> #define kzalloc_obj(P, GFP) \
> __alloc_objs(kzalloc, GFP, typeof(P), 1)
> #define kzalloc_objs(P, COUNT, GFP) \
> __alloc_objs(kzalloc, GFP, typeof(P), COUNT)
> +#define kzalloc_flex(P, FAM, COUNT, GFP) \
> + __alloc_flex(kzalloc, GFP, typeof(P), FAM, COUNT)
>
> /* All kvmalloc aliases for kmalloc_(obj|objs|flex). */
> #define kvmalloc_obj(P, GFP) \
> __alloc_objs(kvmalloc, GFP, typeof(P), 1)
> #define kvmalloc_objs(P, COUNT, GFP) \
> __alloc_objs(kvmalloc, GFP, typeof(P), COUNT)
> +#define kvmalloc_flex(P, FAM, COUNT, GFP) \
> + __alloc_flex(kvmalloc, GFP, typeof(P), FAM, COUNT)
>
> /* All kvzalloc aliases for kmalloc_(obj|objs|flex). */
> #define kvzalloc_obj(P, GFP) \
> __alloc_objs(kvzalloc, GFP, typeof(P), 1)
> #define kvzalloc_objs(P, COUNT, GFP) \
> __alloc_objs(kvzalloc, GFP, typeof(P), COUNT)
> +#define kvzalloc_flex(P, FAM, COUNT, GFP) \
> + __alloc_flex(kvzalloc, GFP, typeof(P), FAM, COUNT)
>
> #define kmem_buckets_alloc(_b, _size, _flags) \
> alloc_hooks(__kmalloc_node_noprof(PASS_BUCKET_PARAMS(_size, _b), _flags, NUMA_NO_NODE))
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-09 16:37 UTC (permalink / raw)
To: Miguel Ojeda
Cc: Sasha Levin, Dave Hansen, Dave Hansen, 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, Jonathan Corbet, Vlastimil Babka,
workflows, ksummit
In-Reply-To: <CANiq72=yOkv_GK=V5k-WTYE-Fv++K+OtVUdrLQcH+75qRMN-Aw@mail.gmail.com>
On Fri, Jan 09, 2026 at 05:30:17PM +0100, Miguel Ojeda wrote:
> On Thu, Jan 8, 2026 at 8:28 PM Lorenzo Stoakes
> <lorenzo.stoakes@oracle.com> wrote:
> >
> > 'You _can_ be more transparent by adding information like this:...'
>
> I am not a native speaker, but my reading of that "can" was that it is
> suggesting ways to be more transparent that may or may not apply in
> particular cases, but the requirement of being transparent was already
> established by the previous sentence:
>
> Second, when making a contribution, be transparent about
> the origin of content in cover letters and changelogs.
>
> Which is reinforced by another imperative in the bullet point about prompts:
>
> If code was largely generated from a single or short set of
> prompts, include those prompts.
>
> Similarly, I read those other "might"s you quote like a set of things
> that could happen or not (and is not exhaustive) in particular cases
> and/or depending on the maintainer etc.
Right I mean I'm not disputing the logic of it, and the document _is_ well
written.
>
> At least that is my reading, and as far as I understood the TAB
> discussions, the goal of this patch was to document that non-trivial
> tool usage needs to be disclosed, including LLM use, and to me the
> patch already did that, but perhaps the wording can be more direct.
Yes, exactly. Really for me the whole thing is about emphasis.
The current version of my proposal is (hopefully) reaching towards quorum as it
takes into account feedback from Dave, Jens, Steven, and others probably who I
forget here (apologies) - see [0] - so I'm hoping that this _should_ be
acceptable as a means of establishing that emphasis without disrupting the
overall aims of the document?
It pleasingly is applicable to _all_ tooling and doesn't take a 'position' per
se on LLMs specifically.
[0]: https://lore.kernel.org/all/1273cff8-b114-4381-bbfe-aa228ce0d20d@lucifer.local/
>
> I hope that clarifies a bit...
Yes indeed :) thanks for that!
>
> Cheers,
> Miguel
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Miguel Ojeda @ 2026-01-09 16:33 UTC (permalink / raw)
To: Steven Rostedt
Cc: Laurent Pinchart, Lorenzo Stoakes, Dan Carpenter, Liam R. Howlett,
Jens Axboe, Dave Hansen, James Bottomley, 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: <20260109105104.57d308f7@gandalf.local.home>
On Fri, Jan 9, 2026 at 4:50 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> In the TAB, where we started discussing this (and I was
> supposed to be the one that wrote the first version, but thankfully Dave
> did a great job at getting it going). The focus was to be to document what
> we currently do in practice when it comes to tool-generated content.
Yes, that matches my understanding of the TAB discussions.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Miguel Ojeda @ 2026-01-09 16:30 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Sasha Levin, Dave Hansen, Dave Hansen, 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, Jonathan Corbet, Vlastimil Babka,
workflows, ksummit
In-Reply-To: <b7469e4e-d711-467f-839f-4a9688d25a23@lucifer.local>
On Thu, Jan 8, 2026 at 8:28 PM Lorenzo Stoakes
<lorenzo.stoakes@oracle.com> wrote:
>
> 'You _can_ be more transparent by adding information like this:...'
I am not a native speaker, but my reading of that "can" was that it is
suggesting ways to be more transparent that may or may not apply in
particular cases, but the requirement of being transparent was already
established by the previous sentence:
Second, when making a contribution, be transparent about
the origin of content in cover letters and changelogs.
Which is reinforced by another imperative in the bullet point about prompts:
If code was largely generated from a single or short set of
prompts, include those prompts.
Similarly, I read those other "might"s you quote like a set of things
that could happen or not (and is not exhaustive) in particular cases
and/or depending on the maintainer etc.
At least that is my reading, and as far as I understood the TAB
discussions, the goal of this patch was to document that non-trivial
tool usage needs to be disclosed, including LLM use, and to me the
patch already did that, but perhaps the wording can be more direct.
I hope that clarifies a bit...
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Steven Rostedt @ 2026-01-09 16:07 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Laurent Pinchart, Dan Carpenter, Liam R. Howlett, Jens Axboe,
Dave Hansen, James Bottomley, 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: <4a8256ae-04b4-4b4e-b638-5e4cbc2362c5@lucifer.local>
On Fri, 9 Jan 2026 15:55:01 +0000
Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> Sure to the above, but it seems (...?) you are ok with my addition to the
> document which hopefully is tempered enough to provide the emphasis I'm
> looking for (note I say - all tools - even if LLMs are the most obvious
> exmaple) - without being so strident as to seem out of scope?
Yes I liked the last example. As I stated, this discussion helped me
understand the issues I had with what you wanted to add. I wanted this
document to be just as applicable to checkpatch and sed scripts as it is to
LLMs. My fear was it was becoming too focused on AI where those that are
submitting checkpatch and coccinelle scripts will think this doesn't apply
to them.
-- Steve
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-09 16:05 UTC (permalink / raw)
To: Steven Rostedt
Cc: Dan Carpenter, Dave Hansen, Dave Hansen, James Bottomley,
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, Jens Axboe
In-Reply-To: <20260109110347.7fa1e655@gandalf.local.home>
On Fri, Jan 09, 2026 at 11:03:47AM -0500, Steven Rostedt wrote:
> On Fri, 9 Jan 2026 15:48:49 +0000
> Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
>
> > On Fri, Jan 09, 2026 at 10:39:24AM -0500, Steven Rostedt wrote:
> > > On Fri, 9 Jan 2026 11:25:57 +0000
> > > Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> > >
> > > > > > I don't really read that as grumpy, I understand wanting to be agreeable
> > > > > > but sometimes it's appropriate to be emphatic, which is the entire purpose
> > > > > > of this amendment.
> > > > > >
> > > > > > Taking into account Jens's input too:
> > > > > >
> > > > > > +If tools permit you to generate series automatically, expect
> > > > > > +additional scrutiny in proportion to how much of it was generated.
> > > > > > +
> > > > > > +As with the output of any tooling, the result maybe incorrect or
> > > > > > +inappropriate, so you are expected to understand and to be able to defend
> > > > > > +everything you submit. If you are unable to do so, then don't submit the
> > > > > > +resulting changes.
> > > > > > +
> > > > > > +If you do so anyway, maintainers are entitled to reject your series without
> > > > > > +detailed review.
> > >
> > > I like it.
> >
> > Hmm, you like my version but then below argue against every point I make in
> > favour of it? I'm confused?
>
> I don't see how it's contradictory to what I expressed later.
Haha I should stop arguing with you then and just nod and shake your hand ;)
OK then I'm good with the above!
Dave - that LGTY?
>
> >
> > Did you mean to say you liked a suggested other revision or... really this
> > one? :)
>
> I like this one, as it relates to any automated tooling (checkpatch and
> coccinelle too, not just AI). Because I do believe this is documenting
> exactly what we do today and have been doing for years.
>
> I always scrutinize tooling more than when someone wrote it. Because using
> tooling myself, there's always that strange corner case that causes the
> tooling to do something you didn't expect. Whereas humans usually make the
> mistakes that you do expect ;-)
Sure well it's actually unexpected somewhat to me that this happens to cover all
that off nicely too.
Obviously the same thing applies to _any_ tooling!
>
>
> >
> > If so and Dave likes it too then LGTM, pending any Linus/other veto.
> >
> > For the rest of your email - a lawyer would say 'asked and answered'. I've
> > responded to every point of yours there about 3 times apiece across the
> > thread and I don't think it's a good use of time to loop around on things!
>
> I believe that you think I disagree more than what I actually do disagree with ;-)
*Nods and shakes hand* ;)
>
> -- Steve
>
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Steven Rostedt @ 2026-01-09 16:03 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Dan Carpenter, Dave Hansen, Dave Hansen, James Bottomley,
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, Jens Axboe
In-Reply-To: <3ef67380-bc8c-42c6-a5f8-416440e4c445@lucifer.local>
On Fri, 9 Jan 2026 15:48:49 +0000
Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> On Fri, Jan 09, 2026 at 10:39:24AM -0500, Steven Rostedt wrote:
> > On Fri, 9 Jan 2026 11:25:57 +0000
> > Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> >
> > > > > I don't really read that as grumpy, I understand wanting to be agreeable
> > > > > but sometimes it's appropriate to be emphatic, which is the entire purpose
> > > > > of this amendment.
> > > > >
> > > > > Taking into account Jens's input too:
> > > > >
> > > > > +If tools permit you to generate series automatically, expect
> > > > > +additional scrutiny in proportion to how much of it was generated.
> > > > > +
> > > > > +As with the output of any tooling, the result maybe incorrect or
> > > > > +inappropriate, so you are expected to understand and to be able to defend
> > > > > +everything you submit. If you are unable to do so, then don't submit the
> > > > > +resulting changes.
> > > > > +
> > > > > +If you do so anyway, maintainers are entitled to reject your series without
> > > > > +detailed review.
> >
> > I like it.
>
> Hmm, you like my version but then below argue against every point I make in
> favour of it? I'm confused?
I don't see how it's contradictory to what I expressed later.
>
> Did you mean to say you liked a suggested other revision or... really this
> one? :)
I like this one, as it relates to any automated tooling (checkpatch and
coccinelle too, not just AI). Because I do believe this is documenting
exactly what we do today and have been doing for years.
I always scrutinize tooling more than when someone wrote it. Because using
tooling myself, there's always that strange corner case that causes the
tooling to do something you didn't expect. Whereas humans usually make the
mistakes that you do expect ;-)
>
> If so and Dave likes it too then LGTM, pending any Linus/other veto.
>
> For the rest of your email - a lawyer would say 'asked and answered'. I've
> responded to every point of yours there about 3 times apiece across the
> thread and I don't think it's a good use of time to loop around on things!
I believe that you think I disagree more than what I actually do disagree with ;-)
-- Steve
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-09 15:55 UTC (permalink / raw)
To: Steven Rostedt
Cc: Laurent Pinchart, Dan Carpenter, Liam R. Howlett, Jens Axboe,
Dave Hansen, James Bottomley, 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: <20260109105104.57d308f7@gandalf.local.home>
On Fri, Jan 09, 2026 at 10:51:04AM -0500, Steven Rostedt wrote:
> On Fri, 9 Jan 2026 10:54:46 +0200
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
>
> > > Which is why I'm tiring myself out with this thread when I have a lot of other
> > > things to do :)
> >
> > Thank you for that. As a lurker in this mail thread, I really appreciate
> > your efforts as they're saving the time I would need to argue as
> > strongly as you do :-)
>
> And even though I'm arguing with Lorenzo, I appreciate him giving his
> feedback. I'm not at all frustrated with him, and his arguments help me
> understand my own ideas about this document.
And to reciprocate - I'm not frustrated or upset with you or anybody else
here or even Linus ;) I see this as healthy debate and that's all I wanted
here.
Civil disagreement is a vital part of a healthy community IMO!
>
> >
> > While I agree with the argument that kernel documentation should not
> > cover every single hypothetical case that one could come up with, the
> > issue at hand here is real (based on the multiple people who have
> > replied saying they have seen it happen), and I don't think anyone
> > expects the problem to disappear magically given the industry trend.
> >
> > It is also absolutely true that actors with questionable ethics will not
> > care about the documentation. I do see value in being able to point
> > developers acting in good faith to the rules, but an even more important
> > point in my opinion is the message your proposal gives to maintainers.
>
> I'm actually not against a document that is all about AI slop. I'm just
> against hijacking this document into being that. This wasn't the purpose of
> this document. In the TAB, where we started discussing this (and I was
> supposed to be the one that wrote the first version, but thankfully Dave
> did a great job at getting it going). The focus was to be to document what
> we currently do in practice when it comes to tool-generated content. Notice
> that the subject of this document doesn't even mention AI.
>
> I personally (and I hope others do too) want to keep this document focused
> on transparency when it comes to tool-generated content which also includes
> testing and such.
>
> Now, in the future there may be a need for a harsher document to cover AI
> slop. I just don't want it to be this document.
>
> I don't think AI is just another tool, but in this document it is, as the
> focus was to talk about all tooling that generates patches (which is
> everything from sed scripts to AI). I don't want this document to be
> focused on AI at all.
>
> If you want something to point to when you receive AI slop, create a
> separate document that is for that purpose only. It will keep this document
> clearer and also be more useful to the one that needs to read the AI slop
> document, as it will be explicitly for them.
Sure to the above, but it seems (...?) you are ok with my addition to the
document which hopefully is tempered enough to provide the emphasis I'm
looking for (note I say - all tools - even if LLMs are the most obvious
exmaple) - without being so strident as to seem out of scope?
>
> -- Steve
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Steven Rostedt @ 2026-01-09 15:51 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Lorenzo Stoakes, Dan Carpenter, Liam R. Howlett, Jens Axboe,
Dave Hansen, James Bottomley, 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: <20260109085446.GA9782@pendragon.ideasonboard.com>
On Fri, 9 Jan 2026 10:54:46 +0200
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> > Which is why I'm tiring myself out with this thread when I have a lot of other
> > things to do :)
>
> Thank you for that. As a lurker in this mail thread, I really appreciate
> your efforts as they're saving the time I would need to argue as
> strongly as you do :-)
And even though I'm arguing with Lorenzo, I appreciate him giving his
feedback. I'm not at all frustrated with him, and his arguments help me
understand my own ideas about this document.
>
> While I agree with the argument that kernel documentation should not
> cover every single hypothetical case that one could come up with, the
> issue at hand here is real (based on the multiple people who have
> replied saying they have seen it happen), and I don't think anyone
> expects the problem to disappear magically given the industry trend.
>
> It is also absolutely true that actors with questionable ethics will not
> care about the documentation. I do see value in being able to point
> developers acting in good faith to the rules, but an even more important
> point in my opinion is the message your proposal gives to maintainers.
I'm actually not against a document that is all about AI slop. I'm just
against hijacking this document into being that. This wasn't the purpose of
this document. In the TAB, where we started discussing this (and I was
supposed to be the one that wrote the first version, but thankfully Dave
did a great job at getting it going). The focus was to be to document what
we currently do in practice when it comes to tool-generated content. Notice
that the subject of this document doesn't even mention AI.
I personally (and I hope others do too) want to keep this document focused
on transparency when it comes to tool-generated content which also includes
testing and such.
Now, in the future there may be a need for a harsher document to cover AI
slop. I just don't want it to be this document.
I don't think AI is just another tool, but in this document it is, as the
focus was to talk about all tooling that generates patches (which is
everything from sed scripts to AI). I don't want this document to be
focused on AI at all.
If you want something to point to when you receive AI slop, create a
separate document that is for that purpose only. It will keep this document
clearer and also be more useful to the one that needs to read the AI slop
document, as it will be explicitly for them.
-- Steve
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-09 15:48 UTC (permalink / raw)
To: Steven Rostedt
Cc: Dan Carpenter, Dave Hansen, Dave Hansen, James Bottomley,
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, Jens Axboe
In-Reply-To: <20260109103924.3de6fb4d@gandalf.local.home>
On Fri, Jan 09, 2026 at 10:39:24AM -0500, Steven Rostedt wrote:
> On Fri, 9 Jan 2026 11:25:57 +0000
> Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
>
> > > > I don't really read that as grumpy, I understand wanting to be agreeable
> > > > but sometimes it's appropriate to be emphatic, which is the entire purpose
> > > > of this amendment.
> > > >
> > > > Taking into account Jens's input too:
> > > >
> > > > +If tools permit you to generate series automatically, expect
> > > > +additional scrutiny in proportion to how much of it was generated.
> > > > +
> > > > +As with the output of any tooling, the result maybe incorrect or
> > > > +inappropriate, so you are expected to understand and to be able to defend
> > > > +everything you submit. If you are unable to do so, then don't submit the
> > > > +resulting changes.
> > > > +
> > > > +If you do so anyway, maintainers are entitled to reject your series without
> > > > +detailed review.
>
> I like it.
Hmm, you like my version but then below argue against every point I make in
favour of it? I'm confused?
Did you mean to say you liked a suggested other revision or... really this
one? :)
If so and Dave likes it too then LGTM, pending any Linus/other veto.
For the rest of your email - a lawyer would say 'asked and answered'. I've
responded to every point of yours there about 3 times apiece across the
thread and I don't think it's a good use of time to loop around on things!
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Steven Rostedt @ 2026-01-09 15:39 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Dan Carpenter, Dave Hansen, Dave Hansen, James Bottomley,
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, Jens Axboe
In-Reply-To: <d6dc605e-2f33-4db2-99d9-4c3c83051ae3@lucifer.local>
On Fri, 9 Jan 2026 11:25:57 +0000
Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> > > I don't really read that as grumpy, I understand wanting to be agreeable
> > > but sometimes it's appropriate to be emphatic, which is the entire purpose
> > > of this amendment.
> > >
> > > Taking into account Jens's input too:
> > >
> > > +If tools permit you to generate series automatically, expect
> > > +additional scrutiny in proportion to how much of it was generated.
> > > +
> > > +As with the output of any tooling, the result maybe incorrect or
> > > +inappropriate, so you are expected to understand and to be able to defend
> > > +everything you submit. If you are unable to do so, then don't submit the
> > > +resulting changes.
> > > +
> > > +If you do so anyway, maintainers are entitled to reject your series without
> > > +detailed review.
I like it.
> >
> > This is too subtle. In real life if we suspect a patchset is AI Slop,
> > then we're going to reject the whole thing immediately. No one is
> > going to review all fifteen patches one by one as if we're searching
> > through monkey poo for edible grains of corn.
I'll repeat here what I mentioned in my other email. Those that send the
slop are NOT GOING TO READ THIS. The ones that are going to read this are
the ones trying to do the right thing.
I don't think this is too subtle. It basically tells honest contributors
what to expect. It doesn't have to be a "Do this or else!" document.
>
> I'm trying to compromise as the general direction on this document is to be
> very soft (see the suggested edits so far).
>
> I get why, but the entire purpose of this amendment is to put emphasis and
> really to stand up as a community and to say clearly this isn't something
> we want.
As I mentioned before. This is to clarify what we expect. Some people may
be harsher on AI slop than others. We don't need to make this document at
the tone of those that hate AI slop the most.
I want the tone to be aimed at people who want to know how to submit
something. Not a tone at those that are going to be doing it wrong *because
they didn't read any documents*.
>
> >
> > The AI slop patches I've seen were not bad actors. Someone saw a
> > TODO in the file and thought that AI could solve it. The patch
> > compiled, it was formatted correctly and the commit message sounded
> > confident so they sent it.
>
> Yes exactly this. Exactly.
>
> I've said it elsewhere, but:
>
> a. People who have good intentions who will take this as a green light to
> just send out fully LLM generated stuff.
I'm pretty sure this document does not express that. Even when being more "soft".
> b. Press coverage (it's already happening) will essentially signal it's a
> green light on this.
>
> For e.g.:
> https://www.phoronix.com/news/Torvalds-Linux-Kernel-AI-Slop
> https://www.theregister.com/2026/01/08/linus_versus_llms_ai_slop_docs/?td=rt-3a
Reading the comments appears to show that most people think AI is mostly
over hyped.
> >
> > To me the audience for this is maybe a team working on AI and they
> > don't have any kernel developers on staff so they assume they're being
> > helpful sending unreviewed patches. The message should be that every
> > patch needs to be reviewed carefully before it is sent upstream. I've
> > been asked to review patches like this in the past. Get outside help
> > if you need to, but every patch needs to be reviewed.
And those people are exactly who will likely not read this document!
>
> Yes exactly.
>
> But also it's useful when dealing even with bad actors to point at the
> community _actually taking a postiion_.
As I stated before. This wasn't the purpose of the document.
>
> And frankly on waiting for it to 'get worse' (i.e. to get like basically
> the rest of open source) - I have little faith the document really will be
> updated to say anything forthright at least at any speed, and by then it'll
> be too little too late.
Honestly, if it gets worse, I would suggest creating a separate document
specifically about AI. This document is just writing down the unwritten
rules we already have with tool-generated content. This document includes
coccinelle and checkpatch.
If we need a "AI slop go away!" document, that should be a separate one.
Feel free to create that and submit an RFC ;-)
-- Steve
>
> The idea the kernel community taking a position doesn't have any impact is
> simply false.
>
> I think far too much thinking in terms of how computers are going on here,
> and too little about how people are.
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-09 15:35 UTC (permalink / raw)
To: Steven Rostedt
Cc: Dan Carpenter, Dave Hansen, Dave Hansen, James Bottomley,
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: <20260109102846.3feeb36a@gandalf.local.home>
On Fri, Jan 09, 2026 at 10:28:46AM -0500, Steven Rostedt wrote:
> On Fri, 9 Jan 2026 07:28:01 +0000
> Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
>
> > > It's better to have a grumpy document, instead of grumpy emails. We
> > > need it to sound grumpy and it needs to be the first paragraph.
>
> I disagree. Specifically because of what Linus had said (see below).
>
> > >
> > > AI Slop: AI can generate a ton of patches automatically which creates a
> > > burden on the upstream maintainers. The maintainers need to review
> > > every line of every patch and they expect the submitters to demonstrate
> > > that even the generated code was verified to be accurate. If you are
> > > unsure of whether a patch is appropriate then do not send it. NO AI
> > > SLOP!
> > >
> > > Of course, sensible people don't need to be told this stuff, but there
> > > are well intentioned people who need it explained.
> > >
> > > regards,
> > > dan carpenter
> > >
> >
> > Exactly.
> >
> > Every version of watering it down just makes it meaningless noise. The point is
> > to emphasise this.
>
> The thing is, the AI slop sending culprits are not going to be the ones to
> read this. It's the people who want to do the right thing that this
> document is focused on and that's why I think it should be more welcoming.
I think you and Linus are wrong about this. There are a class of 'good intent
bad results' people who will absolutely do this _and_ pay attention to the
document.
I expect you as a maintainer must have run into this, I know I have!
And given how inaccurate that register article was, I think you can see that
having something clear matters from that perspective too, in practice.
>
> That said, I just started looking at your other email and that does look
> better. I'll reply there.
Thanks!
>
> -- Steve
Cheers, Lorenzo
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Steven Rostedt @ 2026-01-09 15:28 UTC (permalink / raw)
To: Lorenzo Stoakes
Cc: Dan Carpenter, Dave Hansen, Dave Hansen, James Bottomley,
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: <de260c56-d3dd-449c-b5af-4d85b268f90c@lucifer.local>
On Fri, 9 Jan 2026 07:28:01 +0000
Lorenzo Stoakes <lorenzo.stoakes@oracle.com> wrote:
> > It's better to have a grumpy document, instead of grumpy emails. We
> > need it to sound grumpy and it needs to be the first paragraph.
I disagree. Specifically because of what Linus had said (see below).
> >
> > AI Slop: AI can generate a ton of patches automatically which creates a
> > burden on the upstream maintainers. The maintainers need to review
> > every line of every patch and they expect the submitters to demonstrate
> > that even the generated code was verified to be accurate. If you are
> > unsure of whether a patch is appropriate then do not send it. NO AI
> > SLOP!
> >
> > Of course, sensible people don't need to be told this stuff, but there
> > are well intentioned people who need it explained.
> >
> > regards,
> > dan carpenter
> >
>
> Exactly.
>
> Every version of watering it down just makes it meaningless noise. The point is
> to emphasise this.
The thing is, the AI slop sending culprits are not going to be the ones to
read this. It's the people who want to do the right thing that this
document is focused on and that's why I think it should be more welcoming.
That said, I just started looking at your other email and that does look
better. I'll reply there.
-- Steve
^ permalink raw reply
* Re: [PATCH] [v3] Documentation: Provide guidelines for tool-generated content
From: Lorenzo Stoakes @ 2026-01-09 11:25 UTC (permalink / raw)
To: Dan Carpenter
Cc: Steven Rostedt, Dave Hansen, Dave Hansen, James Bottomley,
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, Jens Axboe
In-Reply-To: <aWDf1zlLTKmw9xnq@stanley.mountain>
On Fri, Jan 09, 2026 at 02:00:39PM +0300, Dan Carpenter wrote:
> On Fri, Jan 09, 2026 at 07:48:35AM +0000, Lorenzo Stoakes wrote:
> > +cc Jens as reference him
> >
> > On Thu, Jan 08, 2026 at 03:14:37PM -0500, Steven Rostedt wrote:
> > > On Thu, 8 Jan 2026 11:50:29 -0800
> > > Dave Hansen <dave@sr71.net> wrote:
> > >
> > > > On 1/8/26 11:23, Lorenzo Stoakes wrote:
> > > > > I'm also not sure why we're losing the scrutiny part?
> > > > >
> > > > > Something like:
> > > > >
> > > > > +If tools permit you to generate series entirely automatically, expect
> > > > > +additional scrutiny.
> > > >
> > > > The reason I resisted integrating this is it tries to draw too specific
> > > > a line in the sand. Someone could rightfully read that and say they
> > > > don't expect additional scrutiny because the entire series was not
> > > > automatically generated.
> >
> > I mean you are making an absolutely valid point, I'd say that'd be a rather
> > silly conclusion to take, but we have to be wary of 'lawyering' the doc
> > here.
> >
> > > >
> > > > What I want to say is: the more automation your tool provides, the more
> > > > scrutiny you get. Maybe:
> > > >
> > > > Expect increasing amounts of maintainer scrutiny on
> > > > contributions that were increasingly generated by tooling.
> > >
> > > Honestly that just sounds "grumpy" to me ;-)
> > >
> > > How about something like:
> > >
> > > All tooling is prone to make mistakes that differ from mistakes
> > > generated by humans. A maintainer may push back harder on
> > > submissions that were entirely or partially generated by tooling
> > > and expect the submitter to demonstrate that even the generated
> > > code was verified to be accurate.
> > >
> > > -- Steve
> >
> > I don't really read that as grumpy, I understand wanting to be agreeable
> > but sometimes it's appropriate to be emphatic, which is the entire purpose
> > of this amendment.
> >
> > Taking into account Jens's input too:
> >
> > +If tools permit you to generate series automatically, expect
> > +additional scrutiny in proportion to how much of it was generated.
> > +
> > +As with the output of any tooling, the result maybe incorrect or
> > +inappropriate, so you are expected to understand and to be able to defend
> > +everything you submit. If you are unable to do so, then don't submit the
> > +resulting changes.
> > +
> > +If you do so anyway, maintainers are entitled to reject your series without
> > +detailed review.
>
> This is too subtle. In real life if we suspect a patchset is AI Slop,
> then we're going to reject the whole thing immediately. No one is
> going to review all fifteen patches one by one as if we're searching
> through monkey poo for edible grains of corn.
I'm trying to compromise as the general direction on this document is to be
very soft (see the suggested edits so far).
I get why, but the entire purpose of this amendment is to put emphasis and
really to stand up as a community and to say clearly this isn't something
we want.
>
> The AI slop patches I've seen were not bad actors. Someone saw a
> TODO in the file and thought that AI could solve it. The patch
> compiled, it was formatted correctly and the commit message sounded
> confident so they sent it.
Yes exactly this. Exactly.
I've said it elsewhere, but:
a. People who have good intentions who will take this as a green light to
just send out fully LLM generated stuff.
b. Press coverage (it's already happening) will essentially signal it's a
green light on this.
For e.g.:
https://www.phoronix.com/news/Torvalds-Linux-Kernel-AI-Slop
https://www.theregister.com/2026/01/08/linus_versus_llms_ai_slop_docs/?td=rt-3a
>
> To me the audience for this is maybe a team working on AI and they
> don't have any kernel developers on staff so they assume they're being
> helpful sending unreviewed patches. The message should be that every
> patch needs to be reviewed carefully before it is sent upstream. I've
> been asked to review patches like this in the past. Get outside help
> if you need to, but every patch needs to be reviewed.
Yes exactly.
But also it's useful when dealing even with bad actors to point at the
community _actually taking a postiion_.
And frankly on waiting for it to 'get worse' (i.e. to get like basically
the rest of open source) - I have little faith the document really will be
updated to say anything forthright at least at any speed, and by then it'll
be too little too late.
The idea the kernel community taking a position doesn't have any impact is
simply false.
I think far too much thinking in terms of how computers are going on here,
and too little about how people are.
>
> regards,
> dan carpenter
Cheers, Lorenzo
^ 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