* maintainer profiles
From: Randy Dunlap @ 2026-04-10 0:18 UTC (permalink / raw)
To: Linux Documentation, Linux Kernel Mailing List
Cc: Jonathan Corbet, Linux Kernel Workflows
Hi,
Is there supposed to be a difference (or distinction) in the contents of
Documentation/process/maintainer-handbooks.rst
and
Documentation/maintainer/maintainer-entry-profile.rst
?
Can they be combined into one location?
--
~Randy
^ permalink raw reply
* Re: [PATCH net-next] docs: netdev: improve wording of reviewer guidance
From: patchwork-bot+netdevbpf @ 2026-04-09 2:10 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, corbet,
skhan, workflows, linux-doc
In-Reply-To: <20260406175334.3153451-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 6 Apr 2026 10:53:34 -0700 you wrote:
> Reword the reviewer guidance based on behavior we see on the list.
> Steer folks:
> - towards sending tags
> - away from process issues.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
>
> [...]
Here is the summary with links:
- [net-next] docs: netdev: improve wording of reviewer guidance
https://git.kernel.org/netdev/net-next/c/bd5c24e4001d
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2] checkpatch: add --json output mode
From: Joe Perches @ 2026-04-08 18:16 UTC (permalink / raw)
To: Sasha Levin, dwaipayanray1, lukas.bulwahn
Cc: mricon, corbet, skhan, apw, workflows, linux-doc, linux-kernel
In-Reply-To: <20260408172435.1268067-1-sashal@kernel.org>
On Wed, 2026-04-08 at 13:24 -0400, Sasha Levin wrote:
Adding --json seems sensible but some of the
added checkpatch code seems odd to me.
> diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
> @@ -2395,6 +2400,18 @@ sub report {
>
> push(our @report, $output);
>
> + if ($json) {
> + our ($realfile, $realline);
Seems an odd way to check if $realfile/$readline is set
> + my %issue = (
> + level => $level,
> + type => $type,
> + message => $msg,
> + );
> + $issue{file} = $realfile if (defined $realfile && $realfile ne '');
> + $issue{line} = $realline + 0 if (defined $realline && $realline);
All the uses of + 0 seem unnecessary, but I gather it's for
string/decimal conversions.
> +sub json_print_result {
> + my ($filename, $total_errors, $total_warnings, $total_checks,
> + $total_lines, $issues, $used_types, $ignored_types) = @_;
> + my %result = (
> + filename => $filename,
> + total_errors => $total_errors + 0,
> + total_warnings => $total_warnings + 0,
> + total_checks => $total_checks + 0,
> + total_lines => $total_lines + 0,
> + issues => $issues,
> + );
> + $result{used_types} = $used_types if (defined $used_types);
> + $result{ignored_types} = $ignored_types if (defined $ignored_types);
> + my $json_encoder = JSON::PP->new->canonical->utf8;
Maybe add JSON pretty too?
> + print $json_encoder->encode(\%result) . "\n";
Still missing parentheses around print args.
I do know that not all existing print uses have parentheses.
I just prefer them to be more like C readable.
> +}
> +
> sub fixup_current_range {
> my ($lineRef, $offset, $length) = @_;
>
> @@ -2690,14 +2724,15 @@ sub process {
> my $last_coalesced_string_linenr = -1;
>
> our @report = ();
> + our @json_issues = ();
> our $cnt_lines = 0;
> our $cnt_error = 0;
> our $cnt_warn = 0;
> our $cnt_chk = 0;
>
> # Trace the real file/line as we go.
> - my $realfile = '';
> - my $realline = 0;
> + our $realfile = '';
> + our $realline = 0;
?
> @@ -7791,18 +7826,27 @@ sub process {
> # If we have no input at all, then there is nothing to report on
> # so just keep quiet.
> if ($#rawlines == -1) {
> + if ($json) {
> + json_print_result($filename, 0, 0, 0, 0, []);
> + }
> exit(0);
> }
>
> # In mailback mode only produce a report in the negative, for
> # things that appear to be patches.
> if ($mailback && ($clean == 1 || !$is_patch)) {
> + if ($json) {
> + json_print_result($filename, 0, 0, 0, 0, []);
> + }
> exit(0);
> }
>
> # This is not a patch, and we are in 'no-patch' mode so
> # just keep quiet.
> if (!$chk_patch && !$is_patch) {
> + if ($json) {
> + json_print_result($filename, 0, 0, 0, 0, []);
> + }
> exit(0);
> }
Duplicated code, maybe use a function or consolidate the code?
Something like:
if (($#rawlines == -1) ||
# If we have no input, there's nothing to report
($mailback && ($clean == 1 || !$is_patch)) ||
# In mailback mode only produce a report for what seems to be a patch
(!$chk_patch && !$is_patch)) {
# This is not a patch, and we are in 'no-patch' mode.
json_print_result($filename, 0, 0, 0, 0, []) if ($json);
exit(0);
}
>
> @@ -7850,6 +7894,13 @@ sub process {
> }
> }
>
> + if ($json) {
> + my @used = sort keys %use_type;
> + my @ignored = sort keys %ignore_type;
> + json_print_result($filename, $cnt_error, $cnt_warn,
> + $cnt_chk, $cnt_lines, \@json_issues,
> + \@used, \@ignored);
> + } else {
> print report_dump();
> if ($summary && !($clean == 1 && $quiet == 1)) {
> print "$filename " if ($summary_file);
> @@ -7878,8 +7929,9 @@ NOTE: Whitespace errors detected.
> EOM
> }
> }
> + } # end !$json
I quite dislike misleading indentation.
Perhaps it's unnecessary here and simpler to use an
exit in the new block at line 7850
>
> - if ($clean == 0 && $fix &&
> + if (!$json && $clean == 0 && $fix &&
> ("@rawlines" ne "@fixed" ||
> $#fixed_inserted >= 0 || $#fixed_deleted >= 0)) {
> my $newfile = $filename;
> @@ -7918,7 +7970,7 @@ EOM
> }
> }
>
> - if ($quiet == 0) {
> + if (!$json && $quiet == 0) {
> print "\n";
> if ($clean == 1) {
> print "$vname has no obvious style problems and is ready for submission.\n";
>
^ permalink raw reply
* [PATCH v2] checkpatch: add --json output mode
From: Sasha Levin @ 2026-04-08 17:24 UTC (permalink / raw)
To: dwaipayanray1, lukas.bulwahn
Cc: joe, mricon, corbet, skhan, apw, workflows, linux-doc,
linux-kernel, Sasha Levin
In-Reply-To: <20260406170039.4034716-1-sashal@kernel.org>
Add a --json flag to checkpatch.pl that emits structured JSON output,
making results machine-parseable for CI systems, IDE integrations, and
AI-assisted code review tools.
The JSON output includes per-file totals (errors, warnings, checks,
lines) and an array of individual issues with structured fields for
level, type, message, file path, and line number.
The --json flag is mutually exclusive with --terse and --emacs.
Normal text output behavior is completely unchanged when --json is
not specified.
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Changes since v1:
- Replace hand-rolled json_escape()/json_encode_issue() with JSON::PP
module (core since perl 5.14), as suggested by Konstantin and Joe
- Factor duplicated empty-result JSON blocks into json_print_result()
helper
- Include used_types and ignored_types arrays in JSON output instead of
suppressing hash_show_words, per Joe's suggestion
---
Documentation/dev-tools/checkpatch.rst | 7 +++
scripts/checkpatch.pl | 64 +++++++++++++++++++++++---
2 files changed, 65 insertions(+), 6 deletions(-)
diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst
index dccede68698ca..17e5744d3dee6 100644
--- a/Documentation/dev-tools/checkpatch.rst
+++ b/Documentation/dev-tools/checkpatch.rst
@@ -64,6 +64,13 @@ Available options:
Output only one line per report.
+ - --json
+
+ Output results as a JSON object. The object includes total error, warning,
+ and check counts, plus an array of individual issues with structured fields
+ for level, type, message, file, and line number. Cannot be used with
+ --terse or --emacs.
+
- --showfile
Show the diffed file position instead of the input file position.
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e56374662ff79..38d1a4a13ee8e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -14,6 +14,7 @@ use File::Basename;
use Cwd 'abs_path';
use Term::ANSIColor qw(:constants);
use Encode qw(decode encode);
+use JSON::PP;
my $P = $0;
my $D = dirname(abs_path($P));
@@ -33,6 +34,7 @@ my $chk_patch = 1;
my $tst_only;
my $emacs = 0;
my $terse = 0;
+my $json = 0;
my $showfile = 0;
my $file = 0;
my $git = 0;
@@ -93,6 +95,7 @@ Options:
--patch treat FILE as patchfile (default)
--emacs emacs compile window format
--terse one line per report
+ --json output results as JSON
--showfile emit diffed file position, not input file position
-g, --git treat FILE as a single commit or git revision range
single git commit with:
@@ -320,6 +323,7 @@ GetOptions(
'patch!' => \$chk_patch,
'emacs!' => \$emacs,
'terse!' => \$terse,
+ 'json!' => \$json,
'showfile!' => \$showfile,
'f|file!' => \$file,
'g|git!' => \$git,
@@ -379,6 +383,7 @@ help($help - 1) if ($help);
die "$P: --git cannot be used with --file or --fix\n" if ($git && ($file || $fix));
die "$P: --verbose cannot be used with --terse\n" if ($verbose && $terse);
+die "$P: --json cannot be used with --terse or --emacs\n" if ($json && ($terse || $emacs));
if ($color =~ /^[01]$/) {
$color = !$color;
@@ -1351,7 +1356,7 @@ for my $filename (@ARGV) {
}
close($FILE);
- if ($#ARGV > 0 && $quiet == 0) {
+ if (!$json && $#ARGV > 0 && $quiet == 0) {
print '-' x length($vname) . "\n";
print "$vname\n";
print '-' x length($vname) . "\n";
@@ -1372,7 +1377,7 @@ for my $filename (@ARGV) {
$file = $oldfile if ($is_git_file);
}
-if (!$quiet) {
+if (!$quiet && !$json) {
hash_show_words(\%use_type, "Used");
hash_show_words(\%ignore_type, "Ignored");
@@ -2395,6 +2400,18 @@ sub report {
push(our @report, $output);
+ if ($json) {
+ our ($realfile, $realline);
+ my %issue = (
+ level => $level,
+ type => $type,
+ message => $msg,
+ );
+ $issue{file} = $realfile if (defined $realfile && $realfile ne '');
+ $issue{line} = $realline + 0 if (defined $realline && $realline);
+ push(our @json_issues, \%issue);
+ }
+
return 1;
}
@@ -2402,6 +2419,23 @@ sub report_dump {
our @report;
}
+sub json_print_result {
+ my ($filename, $total_errors, $total_warnings, $total_checks,
+ $total_lines, $issues, $used_types, $ignored_types) = @_;
+ my %result = (
+ filename => $filename,
+ total_errors => $total_errors + 0,
+ total_warnings => $total_warnings + 0,
+ total_checks => $total_checks + 0,
+ total_lines => $total_lines + 0,
+ issues => $issues,
+ );
+ $result{used_types} = $used_types if (defined $used_types);
+ $result{ignored_types} = $ignored_types if (defined $ignored_types);
+ my $json_encoder = JSON::PP->new->canonical->utf8;
+ print $json_encoder->encode(\%result) . "\n";
+}
+
sub fixup_current_range {
my ($lineRef, $offset, $length) = @_;
@@ -2690,14 +2724,15 @@ sub process {
my $last_coalesced_string_linenr = -1;
our @report = ();
+ our @json_issues = ();
our $cnt_lines = 0;
our $cnt_error = 0;
our $cnt_warn = 0;
our $cnt_chk = 0;
# Trace the real file/line as we go.
- my $realfile = '';
- my $realline = 0;
+ our $realfile = '';
+ our $realline = 0;
my $realcnt = 0;
my $here = '';
my $context_function; #undef'd unless there's a known function
@@ -7791,18 +7826,27 @@ sub process {
# If we have no input at all, then there is nothing to report on
# so just keep quiet.
if ($#rawlines == -1) {
+ if ($json) {
+ json_print_result($filename, 0, 0, 0, 0, []);
+ }
exit(0);
}
# In mailback mode only produce a report in the negative, for
# things that appear to be patches.
if ($mailback && ($clean == 1 || !$is_patch)) {
+ if ($json) {
+ json_print_result($filename, 0, 0, 0, 0, []);
+ }
exit(0);
}
# This is not a patch, and we are in 'no-patch' mode so
# just keep quiet.
if (!$chk_patch && !$is_patch) {
+ if ($json) {
+ json_print_result($filename, 0, 0, 0, 0, []);
+ }
exit(0);
}
@@ -7850,6 +7894,13 @@ sub process {
}
}
+ if ($json) {
+ my @used = sort keys %use_type;
+ my @ignored = sort keys %ignore_type;
+ json_print_result($filename, $cnt_error, $cnt_warn,
+ $cnt_chk, $cnt_lines, \@json_issues,
+ \@used, \@ignored);
+ } else {
print report_dump();
if ($summary && !($clean == 1 && $quiet == 1)) {
print "$filename " if ($summary_file);
@@ -7878,8 +7929,9 @@ NOTE: Whitespace errors detected.
EOM
}
}
+ } # end !$json
- if ($clean == 0 && $fix &&
+ if (!$json && $clean == 0 && $fix &&
("@rawlines" ne "@fixed" ||
$#fixed_inserted >= 0 || $#fixed_deleted >= 0)) {
my $newfile = $filename;
@@ -7918,7 +7970,7 @@ EOM
}
}
- if ($quiet == 0) {
+ if (!$json && $quiet == 0) {
print "\n";
if ($clean == 1) {
print "$vname has no obvious style problems and is ready for submission.\n";
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 0/9] Kernel API Specification Framework
From: Geert Uytterhoeven @ 2026-04-08 12:05 UTC (permalink / raw)
To: Sasha Levin
Cc: Jakub Kicinski, linux-api, linux-kernel, linux-doc, linux-fsdevel,
linux-kbuild, linux-kselftest, workflows, tools, x86,
Thomas Gleixner, Paul E. McKenney, Greg Kroah-Hartman,
Jonathan Corbet, Dmitry Vyukov, Randy Dunlap, Cyril Hrubis,
Kees Cook, Jake Edge, David Laight, Askar Safin, Gabriele Paoloni,
Mauro Carvalho Chehab, Christian Brauner, Alexander Viro,
Andrew Morton, Masahiro Yamada, Shuah Khan, Ingo Molnar,
Arnd Bergmann
In-Reply-To: <abZTg9ZwnE5J4qXa@laps>
Hi Sasha,
On Sun, 15 Mar 2026 at 07:36, Sasha Levin <sashal@kernel.org> wrote:
> On Sat, Mar 14, 2026 at 11:18:22AM -0700, Jakub Kicinski wrote:
> >On Fri, 13 Mar 2026 11:09:10 -0400 Sasha Levin wrote:
> >> This enables static analysis tools to verify userspace API usage at compile
> >> time, test generation based on formal specifications, consistent error handling
> >> validation, automated documentation generation, and formal verification of
> >> kernel interfaces.
> >
> >Could you give some examples? We have machine readable descriptions for
> >Netlink interfaces, we approached syzbot folks and they did not really
> >seem to care for those.
>
> Once the API is in a machine-readable format, we can write formatters to
> output whatever downstream tools need. The kapi tool in the series
> already ships with plain text, JSON, and RST formatters, and adding new
> output formats is straightforward. We don't need to convince the
> syzkaller folks to consume our specs, we can just output them in a
> format that syzkaller already understands.
>
> For example, I have a syzlang formatter that produces the following
> from the sys_read spec in this series:
>
> # --- read ---
> # Read data from a file descriptor
> #
> # @context process, sleepable
> #
> # @capability CAP_DAC_OVERRIDE: Bypass discretionary access control on read permission
> # @capability CAP_DAC_READ_SEARCH: Bypass read permission checks on regular files
> #
> # @error EPERM (-1): Returned by fanotify permission events...
> # @error EINTR (-4): The call was interrupted by a signal before any data was read.
> # @error EIO (-5): A low-level I/O error occurred.
> # @error EBADF (-9): fd is not a valid file descriptor, or fd was not opened for reading.
> # @error EAGAIN (-11): O_NONBLOCK set and read would block.
> # @error EACCES (-13): LSM denied the read operation via security_file_permission().
> # @error EFAULT (-14): buf points outside the accessible address space.
> # @error EISDIR (-21): fd refers to a directory.
> # @error EINVAL (-22): fd not suitable for reading, O_DIRECT misaligned, count negative...
> # @error ENODATA (-61): Data not available in cache...
> # @error EOVERFLOW (-75): File position plus count would exceed LLONG_MAX.
> # @error EOPNOTSUPP (-95): Read not supported for this file type...
> # @error ENOBUFS (-105): Buffer too small for complete notification...
The actual E-values are positive, so I guess you want e.g. -EPERM?
Note that the actual errno values are architecture-specific.
E.g. EOPNOTSUPP can be 45, 95, 122, or 223.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH net-next] docs: netdev: document AI-assisted review tooling
From: Fernando Fernandez Mancera @ 2026-04-06 21:14 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, netdev, workflows,
linux-doc, linux-kernel, mbloch
In-Reply-To: <56c5bdfe2e37738e47b3b4d22e21697c@tipi-net.de>
On 4/6/26 10:24 PM, Nicolai Buchwitz wrote:
> On 6.4.2026 21:58, Fernando Fernandez Mancera wrote:
>> [...]
>
>>
>> Hi Nicolai,
>> maybe I am missing something but [2] isn't from sashiko.dev but from
>> netdev AI CI instead. See: https://netdev-ai.bots.linux.dev/ai-
>> review.html?id=0b114a22-9aab-4265-8bfc-ea1b5bca5514
>
> You're right, I mixed up the two systems - the example I linked was
> from the netdev AI bot, not Sashiko. My mistake on the link.
>
> I stumbled over Sashiko when I noticed the name appearing more often
> in other reviews and then found Jonathan's LWN article about it [1].
>
> Both tools are actively reviewing patches on the list today. I think
> it makes sense to document both rather than just one:
>
> The netdev AI bot at netdev-ai.bots.linux.dev
> Sashiko at sashiko.dev, which posts reviews publicly on its website
> Both use the same review prompts by Chris Mason [2], so there is
> common ground - though results will vary between them due to the
> different AI models (Claude Opus for netdev-ai, Gemini for Sashiko)
> on top of the usual AI uncertainty.
>
> I think it would be useful to document that AI reviews are happening
> but mixing AI bots might confuse people.
>
> Agreed, I'll rework the patch to distinguish the two systems once
> the discussion has been settled.
>
>>
>> The documentation mentioned for running the AI locally is correctly
>> related to netdev AI bot.
>>
>> I think it would be useful to document that AI reviews are happening
>> but mixing AI bots might confuse people.
>>
>>> Check for findings on your submissions and address
>>> +valid ones before a maintainer has to relay the same questions.
>>> +
>>
>> I wonder what would be the consequences for this. If less experienced
>> submitters are expected to address issues pointed out by AI bots they
>> might work on something that isn't valid. AFAIU, the AI output is only
>> forwarded to the submitter after a maintainer reviewed it and believes
>> it makes sense.
>
> Fair point. The wording should make clear that the local tooling is
> an optional aid, not an obligation. I'll soften the language around
> addressing findings.
>
Thank you! Regarding this topic it seems people have been already
discussing this around other subsystems [1]. It might be useful to check
out similar discussions and outcomes.
[1] https://lwn.net/Articles/1064830/
> Would appreciate input on how much detail is appropriate here -
> should the doc just acknowledge that AI review exists and point to
> the tooling, or go into more detail about the workflow?
>
To be honest that is hard for me to tell, I am not a maintainer and not
the one doing the forwarding currently. I think there isn't an official
workflow regarding this. Maybe a good starter would be to just mention
that they exist. Or maybe this is a good opportunity to define an
official workflow!
Thanks,
Fernando.
^ permalink raw reply
* Re: [PATCH net-next] docs: netdev: document AI-assisted review tooling
From: Laurent Pinchart @ 2026-04-06 21:06 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: Fernando Fernandez Mancera, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Jonathan Corbet,
Shuah Khan, netdev, workflows, linux-doc, linux-kernel, mbloch
In-Reply-To: <56c5bdfe2e37738e47b3b4d22e21697c@tipi-net.de>
On Mon, Apr 06, 2026 at 10:24:14PM +0200, Nicolai Buchwitz wrote:
> On 6.4.2026 21:58, Fernando Fernandez Mancera wrote:
> > [...]
>
> >
> > Hi Nicolai,
> > maybe I am missing something but [2] isn't from sashiko.dev but from
> > netdev AI CI instead. See:
> > https://netdev-ai.bots.linux.dev/ai-review.html?id=0b114a22-9aab-4265-8bfc-ea1b5bca5514
>
> You're right, I mixed up the two systems - the example I linked was
> from the netdev AI bot, not Sashiko. My mistake on the link.
>
> I stumbled over Sashiko when I noticed the name appearing more often
> in other reviews and then found Jonathan's LWN article about it [1].
>
> Both tools are actively reviewing patches on the list today. I think
> it makes sense to document both rather than just one:
>
> The netdev AI bot at netdev-ai.bots.linux.dev
> Sashiko at sashiko.dev, which posts reviews publicly on its website
> Both use the same review prompts by Chris Mason [2], so there is
> common ground - though results will vary between them due to the
> different AI models (Claude Opus for netdev-ai, Gemini for Sashiko)
> on top of the usual AI uncertainty.
>
> I think it would be useful to document that AI reviews are happening
> but mixing AI bots might confuse people.
>
> Agreed, I'll rework the patch to distinguish the two systems once
> the discussion has been settled.
>
> > The documentation mentioned for running the AI locally is correctly
> > related to netdev AI bot.
> >
> > I think it would be useful to document that AI reviews are happening
> > but mixing AI bots might confuse people.
> >
> >> Check for findings on your submissions and address
> >> +valid ones before a maintainer has to relay the same questions.
> >> +
> >
> > I wonder what would be the consequences for this. If less experienced
> > submitters are expected to address issues pointed out by AI bots they
> > might work on something that isn't valid. AFAIU, the AI output is only
> > forwarded to the submitter after a maintainer reviewed it and believes
> > it makes sense.
>
> Fair point. The wording should make clear that the local tooling is
> an optional aid, not an obligation. I'll soften the language around
> addressing findings.
>
> Would appreciate input on how much detail is appropriate here -
> should the doc just acknowledge that AI review exists and point to
> the tooling, or go into more detail about the workflow?
In general, if a workflow is expected by a subsystem, it should be
documented. I don't see much to be gained from not telling submitters
what they're expecting to do.
More precisely in this case, as a submitter, I would take it pretty
badly if I was told to act on the output of a tool that is prone to
hallucinations without a maintainer first triaging the comments.
> [1] https://lwn.net/Articles/1063292/
> [2] https://github.com/masoncl/review-prompts/blob/main/kernel/subsystem/networking.md
>
> >> +You can also run AI reviews locally before submitting. Instructions
> >> +and tooling are available at:
> >> +
> >> + https://netdev-ai.bots.linux.dev/ai-local.html
> >> +
> >> Testimonials / feedback
> >> -----------------------
> >>
>
> Thanks for your input
>
> Nicolai
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH] checkpatch: add --json output mode
From: Joe Perches @ 2026-04-06 20:41 UTC (permalink / raw)
To: Sasha Levin, dwaipayanray1, lukas.bulwahn
Cc: corbet, skhan, apw, workflows, linux-doc, linux-kernel
In-Reply-To: <20260406170039.4034716-1-sashal@kernel.org>
On Mon, 2026-04-06 at 13:00 -0400, Sasha Levin wrote:
> Add a --json flag to checkpatch.pl that emits structured JSON output,
> making results machine-parseable for CI systems, IDE integrations, and
> AI-assisted code review tools.
Seems a reasonable idea but perhaps can be improved
> @@ -1372,7 +1376,7 @@ for my $filename (@ARGV) {
> $file = $oldfile if ($is_git_file);
> }
>
> -if (!$quiet) {
> +if (!$quiet && !$json) {
> hash_show_words(\%use_type, "Used");
> hash_show_words(\%ignore_type, "Ignored");
Maybe keep but update?
> @@ -7791,18 +7836,33 @@ sub process {
> # If we have no input at all, then there is nothing to report on
> # so just keep quiet.
> if ($#rawlines == -1) {
> + if ($json) {
> + print '{"filename":"' . json_escape($filename) .
> + '","total_errors":0,"total_warnings":0,' .
poor formatting for that trailing ". please separate by content blocks.
> + '"total_checks":0,"total_lines":0,"issues":[]}' . "\n";
> + }
I'd prefer to keep the print() style used elsewhere
and perhaps the JSON:PP module should be used here.
^ permalink raw reply
* Re: [PATCH] checkpatch: add --json output mode
From: Joe Perches @ 2026-04-06 20:34 UTC (permalink / raw)
To: Konstantin Ryabitsev, Sasha Levin
Cc: dwaipayanray1, lukas.bulwahn, corbet, skhan, apw, workflows,
linux-doc, linux-kernel
In-Reply-To: <20260406-futuristic-lilac-gerbil-6ef4a5@lemur>
On Mon, 2026-04-06 at 15:22 -0400, Konstantin Ryabitsev wrote:
> On Mon, Apr 06, 2026 at 03:13:52PM -0400, Sasha Levin wrote:
> I see that it's writing json out manually, implementing its own escaping.
> > > While there are upsides to not requiring a perl json library, I think it's
> > > fair to expect that people who would want to get json output can probably make
> > > sure that JSON::XS is installed.
> > >
> > > Not a strong object, but seems cleaner that way.
To me too.
JSON:PP is standard since 5.14, and that's 15 years old.
I'd rather just require 5.14 as a minimum and remove
a bunch of other checks too.
^ permalink raw reply
* Re: [PATCH net-next] docs: netdev: document AI-assisted review tooling
From: Nicolai Buchwitz @ 2026-04-06 20:24 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan, netdev, workflows,
linux-doc, linux-kernel, mbloch
In-Reply-To: <345722f0-21b1-4970-8c45-ef85edf9d45b@suse.de>
On 6.4.2026 21:58, Fernando Fernandez Mancera wrote:
> [...]
>
> Hi Nicolai,
> maybe I am missing something but [2] isn't from sashiko.dev but from
> netdev AI CI instead. See:
> https://netdev-ai.bots.linux.dev/ai-review.html?id=0b114a22-9aab-4265-8bfc-ea1b5bca5514
You're right, I mixed up the two systems - the example I linked was
from the netdev AI bot, not Sashiko. My mistake on the link.
I stumbled over Sashiko when I noticed the name appearing more often
in other reviews and then found Jonathan's LWN article about it [1].
Both tools are actively reviewing patches on the list today. I think
it makes sense to document both rather than just one:
The netdev AI bot at netdev-ai.bots.linux.dev
Sashiko at sashiko.dev, which posts reviews publicly on its website
Both use the same review prompts by Chris Mason [2], so there is
common ground - though results will vary between them due to the
different AI models (Claude Opus for netdev-ai, Gemini for Sashiko)
on top of the usual AI uncertainty.
I think it would be useful to document that AI reviews are happening
but mixing AI bots might confuse people.
Agreed, I'll rework the patch to distinguish the two systems once
the discussion has been settled.
>
> The documentation mentioned for running the AI locally is correctly
> related to netdev AI bot.
>
> I think it would be useful to document that AI reviews are happening
> but mixing AI bots might confuse people.
>
>> Check for findings on your submissions and address
>> +valid ones before a maintainer has to relay the same questions.
>> +
>
> I wonder what would be the consequences for this. If less experienced
> submitters are expected to address issues pointed out by AI bots they
> might work on something that isn't valid. AFAIU, the AI output is only
> forwarded to the submitter after a maintainer reviewed it and believes
> it makes sense.
Fair point. The wording should make clear that the local tooling is
an optional aid, not an obligation. I'll soften the language around
addressing findings.
Would appreciate input on how much detail is appropriate here -
should the doc just acknowledge that AI review exists and point to
the tooling, or go into more detail about the workflow?
[1] https://lwn.net/Articles/1063292/
[2]
https://github.com/masoncl/review-prompts/blob/main/kernel/subsystem/networking.md
>
> Thanks,
> Fernando.
>
>> +You can also run AI reviews locally before submitting. Instructions
>> +and tooling are available at:
>> +
>> + https://netdev-ai.bots.linux.dev/ai-local.html
>> +
>> Testimonials / feedback
>> -----------------------
>>
Thanks for your input
Nicolai
^ permalink raw reply
* Re: [PATCH net-next] docs: netdev: document AI-assisted review tooling
From: Fernando Fernandez Mancera @ 2026-04-06 19:58 UTC (permalink / raw)
To: Nicolai Buchwitz, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Jonathan Corbet, Shuah Khan
Cc: netdev, workflows, linux-doc, linux-kernel
In-Reply-To: <20260406-nb-docs-ai-review-v1-1-b58943762ca9@tipi-net.de>
On 4/6/26 9:40 PM, Nicolai Buchwitz wrote:
> Add a section about Sashiko, the Linux Foundation's open-source
> AI review system for kernel patches. Contributors can check review
> feedback on the Sashiko website and address findings proactively,
> reducing the need for maintainers to relay the same questions.
>
> Also point to the local review tooling at netdev-ai.bots.linux.dev
> for contributors who want to run AI reviews before submitting.
>
> Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
> ---
> Sashiko [1] reviews are already being used on the list (e.g. [2])
> but there's no mention of them in the netdev docs. Add a section
> so contributors know they can check and respond to AI review
> feedback directly.
>
> Based on Jakub's reviewer guidance patch [3].
>
> [1] https://sashiko.dev/
> [2] https://lore.kernel.org/all/20260324024235.929875-1-kuba@kernel.org/
> [3] https://lore.kernel.org/all/20260406175334.3153451-1-kuba@kernel.org/
> ---
> Documentation/process/maintainer-netdev.rst | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
>
> diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
> index bda93b459a0533fa1adfd11b756a4f47d1dbaa22..27296afb05d3828a350b4ed5c16907672db9785d 100644
> --- a/Documentation/process/maintainer-netdev.rst
> +++ b/Documentation/process/maintainer-netdev.rst
> @@ -559,6 +559,19 @@ Reviewers are highly encouraged to do more in-depth review of submissions
> and not focus exclusively on process issues, trivial or subjective
> matters like code formatting, tags etc.
>
> +AI-assisted review
> +~~~~~~~~~~~~~~~~~~
> +
> +Patches posted to netdev are automatically reviewed by the Sashiko
> +AI review system (https://sashiko.dev/). Results are posted publicly
> +on the website.
Hi Nicolai,
maybe I am missing something but [2] isn't from sashiko.dev but from
netdev AI CI instead. See:
https://netdev-ai.bots.linux.dev/ai-review.html?id=0b114a22-9aab-4265-8bfc-ea1b5bca5514
The documentation mentioned for running the AI locally is correctly
related to netdev AI bot.
I think it would be useful to document that AI reviews are happening but
mixing AI bots might confuse people.
> Check for findings on your submissions and address
> +valid ones before a maintainer has to relay the same questions.
> +
I wonder what would be the consequences for this. If less experienced
submitters are expected to address issues pointed out by AI bots they
might work on something that isn't valid. AFAIU, the AI output is only
forwarded to the submitter after a maintainer reviewed it and believes
it makes sense.
Thanks,
Fernando.
> +You can also run AI reviews locally before submitting. Instructions
> +and tooling are available at:
> +
> + https://netdev-ai.bots.linux.dev/ai-local.html
> +
> Testimonials / feedback
> -----------------------
>
^ permalink raw reply
* [PATCH net-next] docs: netdev: document AI-assisted review tooling
From: Nicolai Buchwitz @ 2026-04-06 19:40 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Jonathan Corbet, Shuah Khan
Cc: netdev, workflows, linux-doc, linux-kernel, Nicolai Buchwitz
Add a section about Sashiko, the Linux Foundation's open-source
AI review system for kernel patches. Contributors can check review
feedback on the Sashiko website and address findings proactively,
reducing the need for maintainers to relay the same questions.
Also point to the local review tooling at netdev-ai.bots.linux.dev
for contributors who want to run AI reviews before submitting.
Signed-off-by: Nicolai Buchwitz <nb@tipi-net.de>
---
Sashiko [1] reviews are already being used on the list (e.g. [2])
but there's no mention of them in the netdev docs. Add a section
so contributors know they can check and respond to AI review
feedback directly.
Based on Jakub's reviewer guidance patch [3].
[1] https://sashiko.dev/
[2] https://lore.kernel.org/all/20260324024235.929875-1-kuba@kernel.org/
[3] https://lore.kernel.org/all/20260406175334.3153451-1-kuba@kernel.org/
---
Documentation/process/maintainer-netdev.rst | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
index bda93b459a0533fa1adfd11b756a4f47d1dbaa22..27296afb05d3828a350b4ed5c16907672db9785d 100644
--- a/Documentation/process/maintainer-netdev.rst
+++ b/Documentation/process/maintainer-netdev.rst
@@ -559,6 +559,19 @@ Reviewers are highly encouraged to do more in-depth review of submissions
and not focus exclusively on process issues, trivial or subjective
matters like code formatting, tags etc.
+AI-assisted review
+~~~~~~~~~~~~~~~~~~
+
+Patches posted to netdev are automatically reviewed by the Sashiko
+AI review system (https://sashiko.dev/). Results are posted publicly
+on the website. Check for findings on your submissions and address
+valid ones before a maintainer has to relay the same questions.
+
+You can also run AI reviews locally before submitting. Instructions
+and tooling are available at:
+
+ https://netdev-ai.bots.linux.dev/ai-local.html
+
Testimonials / feedback
-----------------------
---
base-commit: d00749db443cf420a882c020ce0e6bb5c43009de
change-id: 20260406-nb-docs-ai-review-28b4ff21cf5e
Best regards,
--
Nicolai Buchwitz <nb@tipi-net.de>
^ permalink raw reply related
* Re: [PATCH] checkpatch: add --json output mode
From: Konstantin Ryabitsev @ 2026-04-06 19:22 UTC (permalink / raw)
To: Sasha Levin
Cc: dwaipayanray1, lukas.bulwahn, joe, corbet, skhan, apw, workflows,
linux-doc, linux-kernel
In-Reply-To: <adQF8LoUf4YH7F98@laps>
On Mon, Apr 06, 2026 at 03:13:52PM -0400, Sasha Levin wrote:
> > I see that it's writing json out manually, implementing its own escaping.
> > While there are upsides to not requiring a perl json library, I think it's
> > fair to expect that people who would want to get json output can probably make
> > sure that JSON::XS is installed.
> >
> > Not a strong object, but seems cleaner that way.
>
> No objection here, but from what I saw the checkpatch code only uses core perl
> packages so I wanted to keep it that way.
I saw that, too, but I think that stems from the expectation that we need to
make it easy to run checkpatch by any random person submitting patches, which
is why, by default, we'll output human-readable results.
JSON output, on the other hand, is mostly useful for specific setups that have
a lot more control over their environment and we don't have to stick to the
"pure perl only" guideline here.
Generating correct json is an exercise in corner cases, which is why I'd
rather this is done with a library that has addressed most of them already.
Regards,
--
KR
^ permalink raw reply
* Re: [PATCH] checkpatch: add --json output mode
From: Sasha Levin @ 2026-04-06 19:13 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: dwaipayanray1, lukas.bulwahn, joe, corbet, skhan, apw, workflows,
linux-doc, linux-kernel
In-Reply-To: <20260406-true-whippet-of-luck-d3c2ba@lemur>
On Mon, Apr 06, 2026 at 03:00:25PM -0400, Konstantin Ryabitsev wrote:
>On Mon, Apr 06, 2026 at 01:00:39PM -0400, Sasha Levin wrote:
>> Add a --json flag to checkpatch.pl that emits structured JSON output,
>> making results machine-parseable for CI systems, IDE integrations, and
>> AI-assisted code review tools.
>>
>> The JSON output includes per-file totals (errors, warnings, checks,
>> lines) and an array of individual issues with structured fields for
>> level, type, message, file path, and line number.
>>
>> The --json flag is mutually exclusive with --terse and --emacs.
>> Normal text output behavior is completely unchanged when --json is
>> not specified.
>
>I see that it's writing json out manually, implementing its own escaping.
>While there are upsides to not requiring a perl json library, I think it's
>fair to expect that people who would want to get json output can probably make
>sure that JSON::XS is installed.
>
>Not a strong object, but seems cleaner that way.
No objection here, but from what I saw the checkpatch code only uses core perl
packages so I wanted to keep it that way.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH] checkpatch: add --json output mode
From: Konstantin Ryabitsev @ 2026-04-06 19:00 UTC (permalink / raw)
To: Sasha Levin
Cc: dwaipayanray1, lukas.bulwahn, joe, corbet, skhan, apw, workflows,
linux-doc, linux-kernel
In-Reply-To: <20260406170039.4034716-1-sashal@kernel.org>
On Mon, Apr 06, 2026 at 01:00:39PM -0400, Sasha Levin wrote:
> Add a --json flag to checkpatch.pl that emits structured JSON output,
> making results machine-parseable for CI systems, IDE integrations, and
> AI-assisted code review tools.
>
> The JSON output includes per-file totals (errors, warnings, checks,
> lines) and an array of individual issues with structured fields for
> level, type, message, file path, and line number.
>
> The --json flag is mutually exclusive with --terse and --emacs.
> Normal text output behavior is completely unchanged when --json is
> not specified.
I see that it's writing json out manually, implementing its own escaping.
While there are upsides to not requiring a perl json library, I think it's
fair to expect that people who would want to get json output can probably make
sure that JSON::XS is installed.
Not a strong object, but seems cleaner that way.
-K
^ permalink raw reply
* Re: [PATCH net-next] docs: netdev: improve wording of reviewer guidance
From: Nicolai Buchwitz @ 2026-04-06 18:37 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, corbet,
skhan, workflows, linux-doc
In-Reply-To: <20260406175334.3153451-1-kuba@kernel.org>
On 6.4.2026 19:53, Jakub Kicinski wrote:
> Reword the reviewer guidance based on behavior we see on the list.
> Steer folks:
> - towards sending tags
> - away from process issues.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> CC: corbet@lwn.net
> CC: skhan@linuxfoundation.org
> CC: workflows@vger.kernel.org
> CC: linux-doc@vger.kernel.org
> ---
> Documentation/process/maintainer-netdev.rst | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/process/maintainer-netdev.rst
> b/Documentation/process/maintainer-netdev.rst
> index 3aa13bc2405d..bda93b459a05 100644
> --- a/Documentation/process/maintainer-netdev.rst
> +++ b/Documentation/process/maintainer-netdev.rst
> @@ -551,10 +551,12 @@ helpful tips please see
> :ref:`development_advancedtopics_reviews`.
>
> It's safe to assume that netdev maintainers know the community and the
> level
> of expertise of the reviewers. The reviewers should not be concerned
> about
> -their comments impeding or derailing the patch flow.
> +their comments impeding or derailing the patch flow. A Reviewed-by tag
> +is understood to mean "I have reviewed this code to the best of my
> ability"
> +rather than "I can attest this code is correct".
>
I had the same hesitation when starting to review on netdev, unsure if
my R-b
carried any value. Therefore I appreciate the addition.
> -Less experienced reviewers are highly encouraged to do more in-depth
> -review of submissions and not focus exclusively on trivial or
> subjective
> +Reviewers are highly encouraged to do more in-depth review of
> submissions
> +and not focus exclusively on process issues, trivial or subjective
> matters like code formatting, tags etc.
>
> Testimonials / feedback
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
^ permalink raw reply
* Re: [PATCH net-next] docs: netdev: improve wording of reviewer guidance
From: Joe Damato @ 2026-04-06 18:09 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, corbet,
skhan, workflows, linux-doc
In-Reply-To: <20260406175334.3153451-1-kuba@kernel.org>
On Mon, Apr 06, 2026 at 10:53:34AM -0700, Jakub Kicinski wrote:
> Reword the reviewer guidance based on behavior we see on the list.
> Steer folks:
> - towards sending tags
> - away from process issues.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> ---
> CC: corbet@lwn.net
> CC: skhan@linuxfoundation.org
> CC: workflows@vger.kernel.org
> CC: linux-doc@vger.kernel.org
> ---
> Documentation/process/maintainer-netdev.rst | 8 +++++---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
Reviewed-by: Joe Damato <joe@dama.to>
^ permalink raw reply
* [PATCH net-next] docs: netdev: improve wording of reviewer guidance
From: Jakub Kicinski @ 2026-04-06 17:53 UTC (permalink / raw)
To: davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, Jakub Kicinski,
corbet, skhan, workflows, linux-doc
Reword the reviewer guidance based on behavior we see on the list.
Steer folks:
- towards sending tags
- away from process issues.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
CC: corbet@lwn.net
CC: skhan@linuxfoundation.org
CC: workflows@vger.kernel.org
CC: linux-doc@vger.kernel.org
---
Documentation/process/maintainer-netdev.rst | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
index 3aa13bc2405d..bda93b459a05 100644
--- a/Documentation/process/maintainer-netdev.rst
+++ b/Documentation/process/maintainer-netdev.rst
@@ -551,10 +551,12 @@ helpful tips please see :ref:`development_advancedtopics_reviews`.
It's safe to assume that netdev maintainers know the community and the level
of expertise of the reviewers. The reviewers should not be concerned about
-their comments impeding or derailing the patch flow.
+their comments impeding or derailing the patch flow. A Reviewed-by tag
+is understood to mean "I have reviewed this code to the best of my ability"
+rather than "I can attest this code is correct".
-Less experienced reviewers are highly encouraged to do more in-depth
-review of submissions and not focus exclusively on trivial or subjective
+Reviewers are highly encouraged to do more in-depth review of submissions
+and not focus exclusively on process issues, trivial or subjective
matters like code formatting, tags etc.
Testimonials / feedback
--
2.53.0
^ permalink raw reply related
* [PATCH] checkpatch: add --json output mode
From: Sasha Levin @ 2026-04-06 17:00 UTC (permalink / raw)
To: dwaipayanray1, lukas.bulwahn
Cc: joe, corbet, skhan, apw, workflows, linux-doc, linux-kernel,
Sasha Levin
Add a --json flag to checkpatch.pl that emits structured JSON output,
making results machine-parseable for CI systems, IDE integrations, and
AI-assisted code review tools.
The JSON output includes per-file totals (errors, warnings, checks,
lines) and an array of individual issues with structured fields for
level, type, message, file path, and line number.
The --json flag is mutually exclusive with --terse and --emacs.
Normal text output behavior is completely unchanged when --json is
not specified.
Assisted-by: Claude:claude-opus-4-6
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Documentation/dev-tools/checkpatch.rst | 7 +++
scripts/checkpatch.pl | 86 ++++++++++++++++++++++++--
2 files changed, 87 insertions(+), 6 deletions(-)
diff --git a/Documentation/dev-tools/checkpatch.rst b/Documentation/dev-tools/checkpatch.rst
index dccede68698ca..17e5744d3dee6 100644
--- a/Documentation/dev-tools/checkpatch.rst
+++ b/Documentation/dev-tools/checkpatch.rst
@@ -64,6 +64,13 @@ Available options:
Output only one line per report.
+ - --json
+
+ Output results as a JSON object. The object includes total error, warning,
+ and check counts, plus an array of individual issues with structured fields
+ for level, type, message, file, and line number. Cannot be used with
+ --terse or --emacs.
+
- --showfile
Show the diffed file position instead of the input file position.
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index e56374662ff79..ed70753ba1afc 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -33,6 +33,7 @@ my $chk_patch = 1;
my $tst_only;
my $emacs = 0;
my $terse = 0;
+my $json = 0;
my $showfile = 0;
my $file = 0;
my $git = 0;
@@ -93,6 +94,7 @@ Options:
--patch treat FILE as patchfile (default)
--emacs emacs compile window format
--terse one line per report
+ --json output results as JSON
--showfile emit diffed file position, not input file position
-g, --git treat FILE as a single commit or git revision range
single git commit with:
@@ -320,6 +322,7 @@ GetOptions(
'patch!' => \$chk_patch,
'emacs!' => \$emacs,
'terse!' => \$terse,
+ 'json!' => \$json,
'showfile!' => \$showfile,
'f|file!' => \$file,
'g|git!' => \$git,
@@ -379,6 +382,7 @@ help($help - 1) if ($help);
die "$P: --git cannot be used with --file or --fix\n" if ($git && ($file || $fix));
die "$P: --verbose cannot be used with --terse\n" if ($verbose && $terse);
+die "$P: --json cannot be used with --terse or --emacs\n" if ($json && ($terse || $emacs));
if ($color =~ /^[01]$/) {
$color = !$color;
@@ -1351,7 +1355,7 @@ for my $filename (@ARGV) {
}
close($FILE);
- if ($#ARGV > 0 && $quiet == 0) {
+ if (!$json && $#ARGV > 0 && $quiet == 0) {
print '-' x length($vname) . "\n";
print "$vname\n";
print '-' x length($vname) . "\n";
@@ -1372,7 +1376,7 @@ for my $filename (@ARGV) {
$file = $oldfile if ($is_git_file);
}
-if (!$quiet) {
+if (!$quiet && !$json) {
hash_show_words(\%use_type, "Used");
hash_show_words(\%ignore_type, "Ignored");
@@ -2395,6 +2399,18 @@ sub report {
push(our @report, $output);
+ if ($json) {
+ our ($realfile, $realline);
+ my %issue = (
+ level => $level,
+ type => $type,
+ message => $msg,
+ );
+ $issue{file} = $realfile if (defined $realfile && $realfile ne '');
+ $issue{line} = $realline + 0 if (defined $realline && $realline);
+ push(our @json_issues, \%issue);
+ }
+
return 1;
}
@@ -2402,6 +2418,34 @@ sub report_dump {
our @report;
}
+sub json_escape {
+ my ($str) = @_;
+ $str =~ s/\\/\\\\/g;
+ $str =~ s/"/\\"/g;
+ $str =~ s/\n/\\n/g;
+ $str =~ s/\r/\\r/g;
+ $str =~ s/\t/\\t/g;
+ $str =~ s/\x08/\\b/g;
+ $str =~ s/\x0c/\\f/g;
+ $str =~ s/([\x00-\x07\x0b\x0e-\x1f])/sprintf("\\u%04x", ord($1))/ge;
+ return $str;
+}
+
+sub json_encode_issue {
+ my ($issue) = @_;
+ my @fields;
+ push(@fields, '"level":"' . json_escape($issue->{level}) . '"');
+ push(@fields, '"type":"' . json_escape($issue->{type}) . '"');
+ push(@fields, '"message":"' . json_escape($issue->{message}) . '"');
+ if (defined $issue->{file}) {
+ push(@fields, '"file":"' . json_escape($issue->{file}) . '"');
+ }
+ if (defined $issue->{line}) {
+ push(@fields, '"line":' . ($issue->{line} + 0));
+ }
+ return '{' . join(',', @fields) . '}';
+}
+
sub fixup_current_range {
my ($lineRef, $offset, $length) = @_;
@@ -2690,14 +2734,15 @@ sub process {
my $last_coalesced_string_linenr = -1;
our @report = ();
+ our @json_issues = ();
our $cnt_lines = 0;
our $cnt_error = 0;
our $cnt_warn = 0;
our $cnt_chk = 0;
# Trace the real file/line as we go.
- my $realfile = '';
- my $realline = 0;
+ our $realfile = '';
+ our $realline = 0;
my $realcnt = 0;
my $here = '';
my $context_function; #undef'd unless there's a known function
@@ -7791,18 +7836,33 @@ sub process {
# If we have no input at all, then there is nothing to report on
# so just keep quiet.
if ($#rawlines == -1) {
+ if ($json) {
+ print '{"filename":"' . json_escape($filename) .
+ '","total_errors":0,"total_warnings":0,' .
+ '"total_checks":0,"total_lines":0,"issues":[]}' . "\n";
+ }
exit(0);
}
# In mailback mode only produce a report in the negative, for
# things that appear to be patches.
if ($mailback && ($clean == 1 || !$is_patch)) {
+ if ($json) {
+ print '{"filename":"' . json_escape($filename) .
+ '","total_errors":0,"total_warnings":0,' .
+ '"total_checks":0,"total_lines":0,"issues":[]}' . "\n";
+ }
exit(0);
}
# This is not a patch, and we are in 'no-patch' mode so
# just keep quiet.
if (!$chk_patch && !$is_patch) {
+ if ($json) {
+ print '{"filename":"' . json_escape($filename) .
+ '","total_errors":0,"total_warnings":0,' .
+ '"total_checks":0,"total_lines":0,"issues":[]}' . "\n";
+ }
exit(0);
}
@@ -7850,6 +7910,19 @@ sub process {
}
}
+ if ($json) {
+ my @issue_strings;
+ foreach my $issue (@json_issues) {
+ push(@issue_strings, json_encode_issue($issue));
+ }
+ print '{"filename":"' . json_escape($filename) . '",' .
+ '"total_errors":' . ($cnt_error + 0) . ',' .
+ '"total_warnings":' . ($cnt_warn + 0) . ',' .
+ '"total_checks":' . ($cnt_chk + 0) . ',' .
+ '"total_lines":' . ($cnt_lines + 0) . ',' .
+ '"issues":[' . join(',', @issue_strings) . ']' .
+ '}' . "\n";
+ } else {
print report_dump();
if ($summary && !($clean == 1 && $quiet == 1)) {
print "$filename " if ($summary_file);
@@ -7878,8 +7951,9 @@ NOTE: Whitespace errors detected.
EOM
}
}
+ } # end !$json
- if ($clean == 0 && $fix &&
+ if (!$json && $clean == 0 && $fix &&
("@rawlines" ne "@fixed" ||
$#fixed_inserted >= 0 || $#fixed_deleted >= 0)) {
my $newfile = $filename;
@@ -7918,7 +7992,7 @@ EOM
}
}
- if ($quiet == 0) {
+ if (!$json && $quiet == 0) {
print "\n";
if ($clean == 1) {
print "$vname has no obvious style problems and is ready for submission.\n";
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] docs: use acknowledgment in submitting-patches
From: Krzysztof Kozlowski @ 2026-04-05 19:30 UTC (permalink / raw)
To: CaoRuichuang, corbet; +Cc: skhan, workflows, linux-doc, linux-kernel
In-Reply-To: <20260405183602.73797-1-create0818@163.com>
On 05/04/2026 20:36, CaoRuichuang wrote:
> Signed-off-by: CaoRuichuang <create0818@163.com>
> ---
> Documentation/process/submitting-patches.rst | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index e69d19a..5c44be9 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -486,9 +486,9 @@ reviewed it as thoroughly as if a Reviewed-by: was provided. Similarly, a key
> user may not have carried out a technical review of the patch, yet they may be
> satisfied with the general approach, the feature or the user-facing interface.
>
> -Acked-by: does not necessarily indicate acknowledgement of the entire patch.
> +Acked-by: does not necessarily indicate acknowledgment of the entire patch.
Pointless change. You are replacing one correct spelling with another
correct one. And your commit msg is empty...
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] docs: use acknowledgment in submitting-patches
From: CaoRuichuang @ 2026-04-05 18:36 UTC (permalink / raw)
To: corbet; +Cc: skhan, workflows, linux-doc, linux-kernel, CaoRuichuang
Signed-off-by: CaoRuichuang <create0818@163.com>
---
Documentation/process/submitting-patches.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index e69d19a..5c44be9 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -486,9 +486,9 @@ reviewed it as thoroughly as if a Reviewed-by: was provided. Similarly, a key
user may not have carried out a technical review of the patch, yet they may be
satisfied with the general approach, the feature or the user-facing interface.
-Acked-by: does not necessarily indicate acknowledgement of the entire patch.
+Acked-by: does not necessarily indicate acknowledgment of the entire patch.
For example, if a patch affects multiple subsystems and has an Acked-by: from
-one subsystem maintainer then this usually indicates acknowledgement of just
+one subsystem maintainer then this usually indicates acknowledgment of just
the part which affects that maintainer's code. Judgement should be used here.
When in doubt people should refer to the original discussion in the mailing
list archives. A "# Suffix" may also be used in this case to clarify.
--
2.39.5 (Apple Git-154)
^ permalink raw reply related
* Documentation: fix two typos in latest update to the security report howto
From: Willy Tarreau @ 2026-04-04 8:20 UTC (permalink / raw)
To: greg
Cc: Jonathan Corbet, skhan, workflows, linux-doc, linux-kernel,
Willy Tarreau
In previous patch "Documentation: clarify the mandatory and desirable
info for security reports" I left two typos that I didn't detect in local
checks. One is "get_maintainers.pl" (no 's' in the script name), and the
other one is a missing closing quote after "Reported-by", which didn't
have effect here but I don't know if it can break rendering elsewhere
(e.g. on the public HTML page). Better fix it before it gets merged.
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
Greg, this is a fix for commit a72b832a482372 that is currently pending
in your char-misc-linus branch.
---
Documentation/process/security-bugs.rst | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 0b1f6d8e3cbe..27b028e85861 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -59,7 +59,7 @@ In addition, the following information are highly desirable:
immediately merged (see Documentation/process/submitting-patches.rst).
This will save some back-and-forth exchanges if it is accepted, and you
will be credited for finding and fixing this issue. Note that in this case
- only a ``Signed-off-by:`` tag is needed, without ``Reported-by:` when the
+ only a ``Signed-off-by:`` tag is needed, without ``Reported-by:`` when the
reporter and author are the same.
* **mitigations**: very often during a bug analysis, some ways of mitigating
@@ -88,7 +88,7 @@ recipients to send a report to. In the Linux kernel, all official maintainers
are trusted, so the consequences of accidentally including the wrong maintainer
are essentially a bit more noise for that person, i.e. nothing dramatic. As
such, a suitable method to figure the list of maintainers (which kernel
-security officers use) is to rely on the get_maintainers.pl script, tuned to
+security officers use) is to rely on the get_maintainer.pl script, tuned to
only report maintainers. This script, when passed a file name, will look for
its path in the MAINTAINERS file to figure a hierarchical list of relevant
maintainers. Calling it a first time with the finest level of filtering will
--
2.52.0
^ permalink raw reply related
* Re: [PATCH v2 2/3] Documentation: explain how to find maintainers addresses for security reports
From: Willy Tarreau @ 2026-04-03 16:39 UTC (permalink / raw)
To: Kees Cook
Cc: greg, edumazet, rdunlap, Jonathan Corbet, skhan, workflows,
linux-doc, linux-kernel
In-Reply-To: <202604030845.9DBD539AB@keescook>
On Fri, Apr 03, 2026 at 08:48:56AM -0700, Kees Cook wrote:
> On Fri, Apr 03, 2026 at 08:20:17AM +0200, Willy Tarreau wrote:
> > [...]
> > +One difficulty for most first-time reporters is to figure the right list of
> > +recipients to send a report to. In the Linux kernel, all official maintainers
> > +are trusted, so the consequences of accidentally including the wrong maintainer
> > +are essentially a bit more noise for that person, i.e. nothing dramatic. As
>
> Yeah, this is the central point: we already trust maintainers; there is
> nothing "special" about security@kernel.org.
Yep!
> > [...]
> > +single line suitable for use in the To: field of a mailer like this::
> > +
> > + $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
> > + --no-git-fallback --no-substatus --no-rolestats --no-multiline \
> > + --pattern-depth 1 drivers/example.c
> > + dev1@example.com, dev2@example.org
>
> To echo Greg, yeah, this is great, and has been an implicit action we've
> done for years, so there's every reason to delegate it to the reporter
> to avoid the round-trip.
Thanks!
> Though I guess we'll see if these new instructions actually change
> anything -- we still have people asking for CVE assignments. :P
I think it will move a little bit, because AI bots read this, so the
annoying ones who used to send us reports they didn't read will make
better ones. We've seen improvements already over the last two months,
with more plain text and less copy-pasted markdown. But maybe the MD
wasn't emitted in the first place. It's also true that the reports
quality has improved and now the tools are used by some experienced
people (but not just them yet). Anyway, we'll see. Now we have just
a link to copy-paste in return, we'll see how it evolves.
Cheers,
Willy
^ permalink raw reply
* Re: [PATCH v2 2/3] Documentation: explain how to find maintainers addresses for security reports
From: Kees Cook @ 2026-04-03 15:48 UTC (permalink / raw)
To: Willy Tarreau
Cc: greg, edumazet, rdunlap, Jonathan Corbet, skhan, workflows,
linux-doc, linux-kernel
In-Reply-To: <20260403062018.31080-3-w@1wt.eu>
On Fri, Apr 03, 2026 at 08:20:17AM +0200, Willy Tarreau wrote:
> [...]
> +One difficulty for most first-time reporters is to figure the right list of
> +recipients to send a report to. In the Linux kernel, all official maintainers
> +are trusted, so the consequences of accidentally including the wrong maintainer
> +are essentially a bit more noise for that person, i.e. nothing dramatic. As
Yeah, this is the central point: we already trust maintainers; there is
nothing "special" about security@kernel.org.
> [...]
> +single line suitable for use in the To: field of a mailer like this::
> +
> + $ ./scripts/get_maintainer.pl --no-tree --no-l --no-r --no-n --m \
> + --no-git-fallback --no-substatus --no-rolestats --no-multiline \
> + --pattern-depth 1 drivers/example.c
> + dev1@example.com, dev2@example.org
To echo Greg, yeah, this is great, and has been an implicit action we've
done for years, so there's every reason to delegate it to the reporter
to avoid the round-trip.
Though I guess we'll see if these new instructions actually change
anything -- we still have people asking for CVE assignments. :P
Reviewed-by: Kees Cook <kees@kernel.org>
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v2 0/3] Documentation: clarify required info in security reports
From: Willy Tarreau @ 2026-04-03 11:51 UTC (permalink / raw)
To: Greg KH
Cc: edumazet, rdunlap, Jonathan Corbet, skhan, workflows, linux-doc,
linux-kernel
In-Reply-To: <2026040324-coping-vacation-7d64@gregkh>
On Fri, Apr 03, 2026 at 01:11:47PM +0200, Greg KH wrote:
> On Fri, Apr 03, 2026 at 08:20:15AM +0200, Willy Tarreau wrote:
> > Hi Greg,
> >
> > I'm sending you the doc clarifications we discussed for the process of
> > reporting security issues. It's cut into the 3 patches I shared this
> > morning on the security list (plus two typos fixed and a paragraph
> > asking for one single issue per report):
> >
> > - one patch that reminds our need for a valid e-mail address
> > - one that explains to reporters how to proceed to find maintainers
> > addresses, hoping we won't have to do it for 90% of reports anymore
> > - one that enumerates basic requirements for every report
> >
> > I think it covers the difficulties we've faced this week. As always,
> > we might possibly find tiny adjustments to add, but my goal would be
> > for such updates to be merged in time to update the public page ASAP
> > so that we can redirect incomplete reports in an attempt to lower the
> > team's current load.
>
> Looks great, thanks. I've applied these to one of my trees and will get
> them to Linus in time for 7.0-final.
Thank you!
Willy
^ 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