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

[PATCH v3 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 problem is becoming urgent and untenable. The increased volume of
patches sent using AI tooling has resulted in dramatically higher
delivery queues and if this change is not implemented, we will have to
start force-unsubscribing addresses that do not show any developer
activity or use similar drastic measures.

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 v3:
- Rebased on v7.4-rc2
- Update the cover to specify that this is urgent
- Link to v2: https://patch.msgid.link/20261020-get-maintainer-the-rest-fallback-v2-0-162aea473488@linuxfoundation.org

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: 7475ea8b58616b33c04afb976cf0fbaad9dd63fb
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 v3 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.56.1

[PATCH v3 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 f271d7413f72..85ba046d66fb 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.56.1

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

[Randy Dunlap]

On 11/13/26 3:02 PM, 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>

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

> ---
>  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 f271d7413f72..85ba046d66fb 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
> 

-- 
~Randy

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

[Joe Perches]

On Fri, 2026-11-13 at 18:02 -0500, 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:

Andrew can you please get this upstream?

> 
>   - 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 problem is becoming urgent and untenable. The increased volume of
> patches sent using AI tooling has resulted in dramatically higher
> delivery queues and if this change is not implemented, we will have to
> start force-unsubscribing addresses that do not show any developer
> activity or use similar drastic measures.
> 
> 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 v3:
> - Rebased on v7.4-rc2
> - Update the cover to specify that this is urgent
> - Link to v2: https://patch.msgid.link/20261020-get-maintainer-the-rest-fallback-v2-0-162aea473488@linuxfoundation.org
> 
> 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: 7475ea8b58616b33c04afb976cf0fbaad9dd63fb
> 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>

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

[Andrew Morton]

On Fri, 13 Nov 2026 18:59:50 -0800 Joe Perches <joe@perches.com> wrote:

> On Fri, 2026-11-13 at 18:02 -0500, 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:
> 
> Andrew can you please get this upstream?

Sure, added to mm.git's 7.4-rcX hotfixes queue, thanks.