[PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Konstantin Ryabitsev]

LKML has become mostly a firehose of patches that are already going to a
subsystem list. The reason is THE REST: it matches every file in the
tree, so get_maintainer.pl adds linux-kernel@vger.kernel.org to every
single patch. During the week of Oct 1-7, 2026:

  - LKML carried 13,641 messages (~1,950/day), 90% of which were also
    sent to at least one other list;
  - with ~2,100 subscribers, that is about 29 million deliveries per
    week for LKML alone.

This issue came up during the 2026 Maintainer Summit and the consensus
was that "always include linux-kernel for every patch" was never the
intent.

This series makes THE REST a fallback as initially intended: it is only
added for a file when no other matching MAINTAINERS section provides a
mailing list that get_maintainer.pl would actually output for it.
Patch 2 updates submitting-patches.rst, which currently tells submitters
to send every patch to LKML.

Several v1 reviewers asked for a catch-all list that would keep carrying
every patch for those who want to follow all kernel development. That
is a worthwhile discussion, but it is separate from this series, which
only restores THE REST to its original role.

Translation maintainers are Cc'd because the it_IT, ja_JP, sp_SP, zh_CN
and zh_TW versions of submitting-patches.rst carry the same "send every
patch to LKML" advice and will need a follow-up update once the English
text is settled.

---
Changes in v2:
- Don't count subscribers-only lists (or moderated lists with
  --no-moderated) as a destination, since get_maintainer.pl doesn't
  output them; v1 sent patches to e.g. fs/squashfs/ to no list at all
- Add submitting-patches.rst update describing LKML as the list of last
  resort (Petr Pavlu)
- Rebase on v7.3
- Link to v1: https://patch.msgid.link/20261008-get-maintainer-the-rest-fallback-v1-1-7d26d0b7aa34@linuxfoundation.org

---
Konstantin Ryabitsev (2):
      get_maintainer: only use THE REST as a fallback
      docs: submitting-patches: make LKML a list of last resort again

 Documentation/process/submitting-patches.rst |  9 ++++--
 scripts/get_maintainer.pl                    | 43 ++++++++++++++++++++++++++++
 2 files changed, 49 insertions(+), 3 deletions(-)
---
base-commit: c03c1a14507dfaf8b856c2608f9ac216021fc222
base-tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
change-id: 20261008-get-maintainer-the-rest-fallback-6655e8a648d4

Best regards,
--  
Konstantin Ryabitsev <konstantin@linuxfoundation.org>

[PATCH v2 1/2] get_maintainer: only use THE REST as a fallback

[Konstantin Ryabitsev]

THE REST matches every file in the tree via "F: *" and "F: */", so
get_maintainer.pl currently adds linux-kernel@vger.kernel.org to every
patch, regardless of whether the touched files already belong to a
subsystem with its own mailing list.

Only add THE REST for a file when no other matching section provides a
mailing list that get_maintainer.pl would actually output. Lists marked
"subscribers-only" are omitted unless --s is given, and lists marked
"moderated" are omitted with --no-moderated, so such lists don't count
as a destination in those cases. Files that match no section, or only
sections without such a list, still fall back to THE REST, so every
patch keeps reaching at least one known-public mailing list.

Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
---
 scripts/get_maintainer.pl | 43 +++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 43 insertions(+)

diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 16b80a700d4a..265245e568c6 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -959,6 +959,15 @@ sub get_maintainers {
 	    $tvi = $end + 1;
 	}
 
+	# THE REST matches every file, so only fall back to it when no
+	# other matching section provides a mailing list for this file
+	# that we would actually output with the current options.
+	my ($the_rest) = grep { get_section_name($_) eq "THE REST" } keys %hash;
+	if (defined($the_rest) &&
+	    grep { $_ != $the_rest && section_has_list($_) } keys %hash) {
+	    delete $hash{$the_rest};
+	}
+
 	foreach my $line (sort {$hash{$b} <=> $hash{$a}} keys %hash) {
 	    add_categories($line, "");
 	    if ($sections) {
@@ -1295,6 +1304,40 @@ sub find_ending_index {
     return $index;
 }
 
+sub get_section_name {
+    my ($index) = @_;
+
+    return $typevalue[find_starting_index($index)];
+}
+
+sub section_has_list {
+    my ($index) = @_;
+
+    my $start = find_starting_index($index);
+    my $end = find_ending_index($index);
+    for (my $i = $start; $i < $end; $i++) {
+	next if ($typevalue[$i] !~ m/^L:\s*(.*)/);
+	my $list_additional = "";
+	if ($1 =~ m/[^\s]+\s+(.*)$/) {
+	    $list_additional = $1;
+	}
+	return 1 if (list_is_selected($list_additional));
+    }
+    return 0;
+}
+
+# Must match the list selection in add_categories()
+sub list_is_selected {
+    my ($list_additional) = @_;
+
+    if ($list_additional =~ m/subscribers-only/) {
+	return $email_subscriber_list;
+    } elsif ($list_additional =~ m/moderated/) {
+	return $email_list && $email_moderated_list;
+    }
+    return $email_list;
+}
+
 sub get_subsystem_name {
     my ($index) = @_;
 

-- 
2.55.0

Re: [PATCH v2 1/2] get_maintainer: only use THE REST as a fallback

[Joe Perches]

On 2026-10-20 08:35, Konstantin Ryabitsev wrote:
> THE REST matches every file in the tree via "F: *" and "F: */", so
> get_maintainer.pl currently adds linux-kernel@vger.kernel.org to every
> patch, regardless of whether the touched files already belong to a
> subsystem with its own mailing list.
> 
> Only add THE REST for a file when no other matching section provides a
> mailing list that get_maintainer.pl would actually output. Lists marked
> "subscribers-only" are omitted unless --s is given, and lists marked
> "moderated" are omitted with --no-moderated, so such lists don't count
> as a destination in those cases. Files that match no section, or only
> sections without such a list, still fall back to THE REST, so every
> patch keeps reaching at least one known-public mailing list.
> 
> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
> ---

I don't disagree that this is useful but v2: no changelog

Perhaps there's a simpler and more generic mechanism.  I'll play with it 
for a couple days.

Re: [PATCH v2 1/2] get_maintainer: only use THE REST as a fallback

[Konstantin Ryabitsev]

On Tue, Oct 20, 2026 at 08:47:01AM -0700, Joe Perches wrote:
> > Only add THE REST for a file when no other matching section provides a
> > mailing list that get_maintainer.pl would actually output. Lists marked
> > "subscribers-only" are omitted unless --s is given, and lists marked
> > "moderated" are omitted with --no-moderated, so such lists don't count
> > as a destination in those cases. Files that match no section, or only
> > sections without such a list, still fall back to THE REST, so every
> > patch keeps reaching at least one known-public mailing list.
> > 
> > Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
> > ---
> 
> I don't disagree that this is useful but v2: no changelog
> 
> Perhaps there's a simpler and more generic mechanism.  I'll play with it for
> a couple days.

It's like to convey the sense of urgency -- with the amount of patches,
automated reviews, and follow-ups being sent daily, having all of them land on
LKML and delivered to 2000+ subscribers... is not sustainable. At this point,
I'm very close to outright banning subscriptions from gmail, outlook and yahoo
addresses. Not sending every single patch to the LKML is a better way to deal
with this.

-K

Re: [PATCH v2 1/2] get_maintainer: only use THE REST as a fallback

[Joe Perches]

On 2026-10-20 08:52, Konstantin Ryabitsev wrote:
> On Tue, Oct 20, 2026 at 08:47:01AM -0700, Joe Perches wrote:
>> > Only add THE REST for a file when no other matching section provides a
>> > mailing list that get_maintainer.pl would actually output. Lists marked
>> > "subscribers-only" are omitted unless --s is given, and lists marked
>> > "moderated" are omitted with --no-moderated, so such lists don't count
>> > as a destination in those cases. Files that match no section, or only
>> > sections without such a list, still fall back to THE REST, so every
>> > patch keeps reaching at least one known-public mailing list.
>> >
>> > Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
>> > ---
>> 
>> I don't disagree that this is useful but v2: no changelog
>> 
>> Perhaps there's a simpler and more generic mechanism.  I'll play with 
>> it for
>> a couple days.
> 
> It's like to convey the sense of urgency -- with the amount of patches,
> automated reviews, and follow-ups being sent daily, having all of them 
> land on
> LKML and delivered to 2000+ subscribers... is not sustainable. At this 
> point,
> I'm very close to outright banning subscriptions from gmail, outlook 
> and yahoo
> addresses. Not sending every single patch to the LKML is a better way 
> to deal
> with this.

No worries.
Apply it and I might deal with later.

[PATCH v2 2/2] docs: submitting-patches: make LKML a list of last resort again

[Konstantin Ryabitsev]

Commit 77167b966b7e ("docs: submitting-patches: clarify the role of
LKML") changed the documentation to say that all patches should be sent
to LKML by default, because get_maintainer.pl always suggested it.

Now that get_maintainer.pl only falls back to THE REST when no other
matching section provides a mailing list, update the documentation to
match: send patches to the subsystem-specific list, and use LKML only
when there isn't one.

Suggested-by: Petr Pavlu <petr.pavlu@suse.com>
Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
---
 Documentation/process/submitting-patches.rst | 9 ++++++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
index 7ae79452e1b4..b4a2750599a7 100644
--- a/Documentation/process/submitting-patches.rst
+++ b/Documentation/process/submitting-patches.rst
@@ -239,9 +239,12 @@ patches as arguments to scripts/get_maintainer.pl).  If you cannot find a
 maintainer for the subsystem you are working on, Andrew Morton
 (akpm@linux-foundation.org) serves as a maintainer of last resort.
 
-linux-kernel@vger.kernel.org should be used by default for all patches, but the
-volume on that list has caused a number of developers to tune it out.  Please
-do not spam unrelated lists and unrelated people, though.
+You should also normally choose at least one mailing list to receive a copy of
+your patch set.  Look in the MAINTAINERS file for a subsystem-specific list;
+your patch will probably get more attention there.
+linux-kernel@vger.kernel.org functions as a list of last resort for patches
+that do not have a subsystem-specific list.  Please do not spam unrelated lists
+and unrelated people, though.
 
 Many kernel-related lists are hosted at kernel.org; you can find a list
 of them at https://subspace.kernel.org.  There are kernel-related lists

-- 
2.55.0

Re: [PATCH v2 2/2] docs: submitting-patches: make LKML a list of last resort again

[Randy Dunlap]

On 10/20/26 8:35 AM, Konstantin Ryabitsev wrote:
> Commit 77167b966b7e ("docs: submitting-patches: clarify the role of
> LKML") changed the documentation to say that all patches should be sent
> to LKML by default, because get_maintainer.pl always suggested it.
> 
> Now that get_maintainer.pl only falls back to THE REST when no other
> matching section provides a mailing list, update the documentation to
> match: send patches to the subsystem-specific list, and use LKML only
> when there isn't one.
> 
> Suggested-by: Petr Pavlu <petr.pavlu@suse.com>
> Signed-off-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org>
> ---
>  Documentation/process/submitting-patches.rst | 9 ++++++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst
> index 7ae79452e1b4..b4a2750599a7 100644
> --- a/Documentation/process/submitting-patches.rst
> +++ b/Documentation/process/submitting-patches.rst
> @@ -239,9 +239,12 @@ patches as arguments to scripts/get_maintainer.pl).  If you cannot find a
>  maintainer for the subsystem you are working on, Andrew Morton
>  (akpm@linux-foundation.org) serves as a maintainer of last resort.
>  
> -linux-kernel@vger.kernel.org should be used by default for all patches, but the
> -volume on that list has caused a number of developers to tune it out.  Please
> -do not spam unrelated lists and unrelated people, though.
> +You should also normally choose at least one mailing list to receive a copy of
> +your patch set.  Look in the MAINTAINERS file for a subsystem-specific list;
> +your patch will probably get more attention there.
> +linux-kernel@vger.kernel.org functions as a list of last resort for patches
> +that do not have a subsystem-specific list.  Please do not spam unrelated lists
> +and unrelated people, though.
>  
>  Many kernel-related lists are hosted at kernel.org; you can find a list
>  of them at https://subspace.kernel.org.  There are kernel-related lists
> 

Acked-by: Randy Dunlap <rdunlap@infradead.org>
Thanks.

-- 
~Randy

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Joe Perches]

On 2026-10-20 08:35, Konstantin Ryabitsev wrote:
> LKML has become mostly a firehose of patches that are already going to 
> a
> subsystem list. The reason is THE REST: it matches every file in the
> tree, so get_maintainer.pl adds linux-kernel@vger.kernel.org to every
> single patch. During the week of Oct 1-7, 2026:
> 
>   - LKML carried 13,641 messages (~1,950/day), 90% of which were also
>     sent to at least one other list;
>   - with ~2,100 subscribers, that is about 29 million deliveries per
>     week for LKML alone.
> 
> This issue came up during the 2026 Maintainer Summit and the consensus
> was that "always include linux-kernel for every patch" was never the
> intent.

That's not actually true.

Lkml was the default mailing list and other lists were specific to their 
interests.

> This series makes THE REST a fallback as initially intended: it is only
> added for a file when no other matching MAINTAINERS section provides a
> mailing list that get_maintainer.pl would actually output for it.

> Patch 2 updates submitting-patches.rst, which currently tells 
> submitters
> to send every patch to LKML.

Which was the documented and then desired behavior.

No worries, things change.

I too stopped subscribing to lkml a long while ago.

Re: [PATCH v2 0/2] get_maintainer: stop sending every patch to LKML

[Weijie Yuan]

On 2026-10-20 11:35:24 -0400, Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:

> LKML has become mostly a firehose of patches that are already going to a
> subsystem list. The reason is THE REST: it matches every file in the
> tree, so get_maintainer.pl adds linux-kernel@vger.kernel.org to every
> single patch. During the week of Oct 1-7, 2026:
> 
>   - LKML carried 13,641 messages (~1,950/day), 90% of which were also
>     sent to at least one other list;
>   - with ~2,100 subscribers, that is about 29 million deliveries per
>     week for LKML alone.
> 
> This issue came up during the 2026 Maintainer Summit and the consensus
> was that "always include linux-kernel for every patch" was never the
> intent.
> 
> This series makes THE REST a fallback as initially intended: it is only
> added for a file when no other matching MAINTAINERS section provides a
> mailing list that get_maintainer.pl would actually output for it.
> Patch 2 updates submitting-patches.rst, which currently tells submitters
> to send every patch to LKML.
> 
> Several v1 reviewers asked for a catch-all list that would keep carrying
> every patch for those who want to follow all kernel development. That
> is a worthwhile discussion, but it is separate from this series, which
> only restores THE REST to its original role.
> 
> Translation maintainers are Cc'd because the it_IT, ja_JP, sp_SP, zh_CN
> and zh_TW versions of submitting-patches.rst carry the same "send every
> patch to LKML" advice and will need a follow-up update once the English
> text is settled.

Thanks. Added to the todo list.