* Re: maintainer profiles
From: Mauro Carvalho Chehab @ 2026-04-14 12:37 UTC (permalink / raw)
To: Dan Williams
Cc: Jonathan Corbet, Randy Dunlap, Linux Documentation,
Linux Kernel Mailing List, Linux Kernel Workflows
In-Reply-To: <69dd6299440be_147c801005b@djbw-dev.notmuch>
On Mon, 13 Apr 2026 14:39:37 -0700
Dan Williams <djbw@kernel.org> wrote:
> Jonathan Corbet wrote:
> > Randy Dunlap <rdunlap@infradead.org> writes:
> >
> > > 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?
> >
> > Late to the party, sorry ... the original idea, I believe, was that
> > maintainer-handbooks.rst would be for developers looking for a guidebook
> > for a specific subsystem, while maintainer-entry-profile.rst was about
> > how maintainers themselves should write their subsystem guide.
> > Doubtless things have drifted since then... But the intended audiences
> > were different, so it might be good to think about bringing them back
> > into focus.
>
> Right, I think something (roughly / hand-wavy) like the below is the
> intent. However, as I write that I notice that the combined list is a
> bit of a mess. I also notice that there are more "P:" entries in
> MAINTAINERS than there are entries in this maintainer-handbooks.rst
> list.
>
> So this probably wants to be a script that can build Documentation links
> from MAINTAINERS, or otherwise provide a script for developers to query
> a kernel tree for additional submission guides. It is probably not as
> important for the built docs to link all guides as it is for developers
> (or their agents) to live query a tree they are developing against.
There is already a Python script which parses MAINTAINERS file
(Documentation/sphinx/maintainers_include.py).
Currently, it expects a Sphinx meta-tag inside
Documentation/process/maintainers.rst:
.. maintainers-include::
I guess it shouldn't be hard to add support there for a
.. maintainers-profile::
Making it creating a set of cross-references is probably easy. Not
sure how easy/hard would be to create a TOC tree, though.
> Note the problem goes both ways, there are P: entries not in the
> combined handbook list, like the Security subsystem, and there are
> handbook entries without a P:, like the Tip tree.
Assuming we add such extension, we'll need to sync the P: entries.
I'll take a look on trying to extend the Sphinx maintainers
extension.
>
> diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst
> index 6020d188e13d..58e2af333692 100644
> --- a/Documentation/maintainer/maintainer-entry-profile.rst
> +++ b/Documentation/maintainer/maintainer-entry-profile.rst
> @@ -92,24 +92,8 @@ full series, or privately send a reminder email. This section might also
> list how review works for this code area and methods to get feedback
> that are not directly from the maintainer.
>
> -Existing profiles
> ------------------
> -
> -For now, existing maintainer profiles are listed here; we will likely want
> -to do something different in the near future.
> -
> -.. toctree::
> - :maxdepth: 1
> -
> - ../doc-guide/maintainer-profile
> - ../nvdimm/maintainer-entry-profile
> - ../arch/riscv/patch-acceptance
> - ../process/maintainer-soc
> - ../process/maintainer-soc-clean-dts
> - ../driver-api/media/maintainer-entry-profile
> - ../process/maintainer-netdev
> - ../driver-api/vfio-pci-device-specific-driver-acceptance
> - ../nvme/feature-and-quirk-policy
> - ../filesystems/nfs/nfsd-maintainer-entry-profile
> - ../filesystems/xfs/xfs-maintainer-entry-profile
> - ../mm/damon/maintainer-profile
> +Maintainer Handbooks
> +--------------------
> +
> +For examples of other subsystem handbooks see
> +Documentation/process/maintainer-handbooks.rst.
> diff --git a/Documentation/process/maintainer-handbooks.rst b/Documentation/process/maintainer-handbooks.rst
> index 976391cec528..bc9299a04b1f 100644
> --- a/Documentation/process/maintainer-handbooks.rst
> +++ b/Documentation/process/maintainer-handbooks.rst
> @@ -9,14 +9,33 @@ The purpose of this document is to provide subsystem specific information
> which is supplementary to the general development process handbook
> :ref:`Documentation/process <development_process_main>`.
>
> +For developers, see below for all the known subsystem specific guides.
> +If the subsystem you are contributing to does not have a guide listed
> +here, it is fair to seek clarification of questions raised in
> +Documentation/maintainer/maintainer-entry-profile.rst.
> +
> +For maintainers, consider documenting additional requirements and
> +expectations if submissions routinely overlook specific submission
> +criteria. See Documentation/maintainer/maintainer-entry-profile.rst.
> +
> Contents:
>
> .. toctree::
> :numbered:
> :maxdepth: 2
>
> + maintainer-kvm-x86
> maintainer-netdev
> maintainer-soc
> maintainer-soc-clean-dts
> + maintainer-soc-clean-dts
> maintainer-tip
> - maintainer-kvm-x86
> + ../arch/riscv/patch-acceptance
> + ../doc-guide/maintainer-profile
> + ../driver-api/media/maintainer-entry-profile
> + ../driver-api/vfio-pci-device-specific-driver-acceptance
> + ../filesystems/nfs/nfsd-maintainer-entry-profile
> + ../filesystems/xfs/xfs-maintainer-entry-profile
> + ../mm/damon/maintainer-profile
> + ../nvdimm/maintainer-entry-profile
> + ../nvme/feature-and-quirk-policy
Sounds good on my eyes.
Reviewed-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
--
Thanks,
Mauro
^ permalink raw reply
* How to backport (with conflict resolution) CVE-fixing commits to stable releases?
From: Quentin Schulz @ 2026-04-14 11:40 UTC (permalink / raw)
To: Jonathan Corbet, Greg Kroah-Hartman, Sasha Levin,
CVE Assignment Team
Cc: workflows, stable, Heiko Stuebner
Hi all,
I would like to backport
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=a7ac22d53d0990152b108c3f4fe30df45fcb0181
to linux-6.12.y. It is not a conflict-less cherry-pick as many commits
have been made to that file between 6.12 and 6.19 when it was fixed,
which makes git-cherry-pick conflict. I believe I have a patch that
implements the same logic (moving code around, just that that code is
different since it was modified after 6.12) in linux-6.12.y that does
the original commit in 6.19.
My understanding is that this means this patch fits Option 3:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-3.
1) It is not specified there what to do with git trailer tags, e.g.
Reviewed-by, Acked-by, Tested-by. I'm assuming
https://www.kernel.org/doc/html/latest/process/submitting-patches.html#using-reported-by-tested-by-reviewed-by-suggested-by-and-fixes
"""
However if the patch has changed substantially in following version,
these tags might not be applicable anymore and thus should be removed.
Usually removal of someone’s Acked-by, Tested-by or Reviewed-by tags
should be mentioned in the patch changelog with an explanation (after
the ‘---’ separator).
"""
applies here but I think it should be made explicit in
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-3.
Did I understand this correctly? Could we specify in
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-3
what to do with those tags? Also should the people whose tags are
removed be added in Cc of the backport patch (they won't be
automatically with git-send-email anymore since their tags are removed)?
2) I'm also wondering if we should strip the Signed-off-by tags used in
the original patch's delivery path to Linus. After all, it'll go through
a different path: to stable "directly". For this specific commit, it
doesn't matter as the Signed-off-by are for all authors including the
maintainer as last, but the question remains, I don't believe it's
always the case the last author Signed-off-by is the same as the
maintainers' first and last Signed-off-by in the delivery path. What
should we do?
3) Finally, the last question I have is whether it's
required/recommended, and if so, how, to tell maintainers of
https://git.kernel.org/pub/scm/linux/security/vulns.git that this patch
is for CVE X, in my case
https://git.kernel.org/pub/scm/linux/security/vulns.git/tree/cve/published/2026/CVE-2026-22986.dyad.
Maybe their tooling will automatically pick it up once merged, but I
couldn't find documentation either in
https://www.kernel.org/doc/html/latest/process or nor in the vulns git
repo what to do. Did I miss or misread something? Is there anything we
could add to
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html,
https://www.kernel.org/doc/html/latest/process/cve.html and/or
https://git.kernel.org/pub/scm/linux/security/vulns.git to make this
clearer? Greg seems to be saying "patches to vulns.git welcome" in
http://www.kroah.com/log/blog/2026/02/16/linux-cve-assignment-process/
(Chapter "Changing a CVE"). But also "this is automated" in
http://www.kroah.com/log/blog/2025/12/15/tracking-kernel-commits-across-branches/.
However, those aren't on kernel.org :)
I hope I got all the right mailing lists and maintainers in the mail
recipients, feel free to add more appropriate ones.
Cheers,
Quentin
^ permalink raw reply
* Re: maintainer profiles
From: Krzysztof Kozlowski @ 2026-04-14 11:18 UTC (permalink / raw)
To: Randy Dunlap, Linux Documentation, Linux Kernel Mailing List
Cc: Jonathan Corbet, Linux Kernel Workflows
In-Reply-To: <b7775383-da94-4098-8af9-2f672c4f1a71@infradead.org>
On 10/04/2026 02:18, Randy Dunlap wrote:
> 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?
Yes, please! Including also the location of actual profiles. I am mostly
looking at them in the sources directly, not web docs, so confusing and
annoying to find them distributed.
Best regards,
Krzysztof
^ permalink raw reply
* Re: maintainer profiles
From: Randy Dunlap @ 2026-04-13 23:08 UTC (permalink / raw)
To: Dan Williams, Jonathan Corbet, Linux Documentation,
Linux Kernel Mailing List
Cc: Linux Kernel Workflows
In-Reply-To: <69dd6299440be_147c801005b@djbw-dev.notmuch>
Hi,
On 4/13/26 2:39 PM, Dan Williams wrote:
> Jonathan Corbet wrote:
>> Randy Dunlap <rdunlap@infradead.org> writes:
>>
>>> 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?
>>
>> Late to the party, sorry ... the original idea, I believe, was that
>> maintainer-handbooks.rst would be for developers looking for a guidebook
>> for a specific subsystem, while maintainer-entry-profile.rst was about
>> how maintainers themselves should write their subsystem guide.
>> Doubtless things have drifted since then... But the intended audiences
>> were different, so it might be good to think about bringing them back
>> into focus.
>
> Right, I think something (roughly / hand-wavy) like the below is the
> intent. However, as I write that I notice that the combined list is a
> bit of a mess. I also notice that there are more "P:" entries in
> MAINTAINERS than there are entries in this maintainer-handbooks.rst
> list.
>
> So this probably wants to be a script that can build Documentation links
> from MAINTAINERS, or otherwise provide a script for developers to query
> a kernel tree for additional submission guides. It is probably not as
> important for the built docs to link all guides as it is for developers
> (or their agents) to live query a tree they are developing against.
>
> Note the problem goes both ways, there are P: entries not in the
> combined handbook list, like the Security subsystem, and there are
> handbook entries without a P:, like the Tip tree.
I had not (and have not) checked on the P: entries.
However, this patch is close to where I already was, but it (and my
patch) causes some problems. (I dropped the duplicate
maintainer-soc-clean-dts entry.)
E.g., maintainer-handbooks uses :numbered:, but the Media and XFS
entries are already numbered, so Sphinx complains about that.
I think that numbering isn't needed, so I tried dropping that,
but the Media and XFS entries are still numbered, so it looks
messy, but that may be OK (better) than 2 mixed lists.
I'm not finding a satisfactory answer here (yet).
diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst> index 6020d188e13d..58e2af333692 100644
> --- a/Documentation/maintainer/maintainer-entry-profile.rst
> +++ b/Documentation/maintainer/maintainer-entry-profile.rst
> @@ -92,24 +92,8 @@ full series, or privately send a reminder email. This section might also
> list how review works for this code area and methods to get feedback
> that are not directly from the maintainer.
>
> -Existing profiles
> ------------------
> -
> -For now, existing maintainer profiles are listed here; we will likely want
> -to do something different in the near future.
> -
> -.. toctree::
> - :maxdepth: 1
> -
> - ../doc-guide/maintainer-profile
> - ../nvdimm/maintainer-entry-profile
> - ../arch/riscv/patch-acceptance
> - ../process/maintainer-soc
> - ../process/maintainer-soc-clean-dts
> - ../driver-api/media/maintainer-entry-profile
> - ../process/maintainer-netdev
> - ../driver-api/vfio-pci-device-specific-driver-acceptance
> - ../nvme/feature-and-quirk-policy
> - ../filesystems/nfs/nfsd-maintainer-entry-profile
> - ../filesystems/xfs/xfs-maintainer-entry-profile
> - ../mm/damon/maintainer-profile
> +Maintainer Handbooks
> +--------------------
> +
> +For examples of other subsystem handbooks see
> +Documentation/process/maintainer-handbooks.rst.
> diff --git a/Documentation/process/maintainer-handbooks.rst b/Documentation/process/maintainer-handbooks.rst
> index 976391cec528..bc9299a04b1f 100644
> --- a/Documentation/process/maintainer-handbooks.rst
> +++ b/Documentation/process/maintainer-handbooks.rst
> @@ -9,14 +9,33 @@ The purpose of this document is to provide subsystem specific information
> which is supplementary to the general development process handbook
> :ref:`Documentation/process <development_process_main>`.
>
> +For developers, see below for all the known subsystem specific guides.
> +If the subsystem you are contributing to does not have a guide listed
> +here, it is fair to seek clarification of questions raised in
> +Documentation/maintainer/maintainer-entry-profile.rst.
> +
> +For maintainers, consider documenting additional requirements and
> +expectations if submissions routinely overlook specific submission
> +criteria. See Documentation/maintainer/maintainer-entry-profile.rst.
> +
> Contents:
>
> .. toctree::
> :numbered:
> :maxdepth: 2
>
> + maintainer-kvm-x86
> maintainer-netdev
> maintainer-soc
> maintainer-soc-clean-dts
> + maintainer-soc-clean-dts
> maintainer-tip
> - maintainer-kvm-x86
> + ../arch/riscv/patch-acceptance
> + ../doc-guide/maintainer-profile
> + ../driver-api/media/maintainer-entry-profile
> + ../driver-api/vfio-pci-device-specific-driver-acceptance
> + ../filesystems/nfs/nfsd-maintainer-entry-profile
> + ../filesystems/xfs/xfs-maintainer-entry-profile
> + ../mm/damon/maintainer-profile
> + ../nvdimm/maintainer-entry-profile
> + ../nvme/feature-and-quirk-policy
>
>
--
~Randy
^ permalink raw reply
* Re: maintainer profiles
From: Dan Williams @ 2026-04-13 21:39 UTC (permalink / raw)
To: Jonathan Corbet, Randy Dunlap, Linux Documentation,
Linux Kernel Mailing List
Cc: Linux Kernel Workflows
In-Reply-To: <87wlyawum7.fsf@trenco.lwn.net>
Jonathan Corbet wrote:
> Randy Dunlap <rdunlap@infradead.org> writes:
>
> > 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?
>
> Late to the party, sorry ... the original idea, I believe, was that
> maintainer-handbooks.rst would be for developers looking for a guidebook
> for a specific subsystem, while maintainer-entry-profile.rst was about
> how maintainers themselves should write their subsystem guide.
> Doubtless things have drifted since then... But the intended audiences
> were different, so it might be good to think about bringing them back
> into focus.
Right, I think something (roughly / hand-wavy) like the below is the
intent. However, as I write that I notice that the combined list is a
bit of a mess. I also notice that there are more "P:" entries in
MAINTAINERS than there are entries in this maintainer-handbooks.rst
list.
So this probably wants to be a script that can build Documentation links
from MAINTAINERS, or otherwise provide a script for developers to query
a kernel tree for additional submission guides. It is probably not as
important for the built docs to link all guides as it is for developers
(or their agents) to live query a tree they are developing against.
Note the problem goes both ways, there are P: entries not in the
combined handbook list, like the Security subsystem, and there are
handbook entries without a P:, like the Tip tree.
diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst
index 6020d188e13d..58e2af333692 100644
--- a/Documentation/maintainer/maintainer-entry-profile.rst
+++ b/Documentation/maintainer/maintainer-entry-profile.rst
@@ -92,24 +92,8 @@ full series, or privately send a reminder email. This section might also
list how review works for this code area and methods to get feedback
that are not directly from the maintainer.
-Existing profiles
------------------
-
-For now, existing maintainer profiles are listed here; we will likely want
-to do something different in the near future.
-
-.. toctree::
- :maxdepth: 1
-
- ../doc-guide/maintainer-profile
- ../nvdimm/maintainer-entry-profile
- ../arch/riscv/patch-acceptance
- ../process/maintainer-soc
- ../process/maintainer-soc-clean-dts
- ../driver-api/media/maintainer-entry-profile
- ../process/maintainer-netdev
- ../driver-api/vfio-pci-device-specific-driver-acceptance
- ../nvme/feature-and-quirk-policy
- ../filesystems/nfs/nfsd-maintainer-entry-profile
- ../filesystems/xfs/xfs-maintainer-entry-profile
- ../mm/damon/maintainer-profile
+Maintainer Handbooks
+--------------------
+
+For examples of other subsystem handbooks see
+Documentation/process/maintainer-handbooks.rst.
diff --git a/Documentation/process/maintainer-handbooks.rst b/Documentation/process/maintainer-handbooks.rst
index 976391cec528..bc9299a04b1f 100644
--- a/Documentation/process/maintainer-handbooks.rst
+++ b/Documentation/process/maintainer-handbooks.rst
@@ -9,14 +9,33 @@ The purpose of this document is to provide subsystem specific information
which is supplementary to the general development process handbook
:ref:`Documentation/process <development_process_main>`.
+For developers, see below for all the known subsystem specific guides.
+If the subsystem you are contributing to does not have a guide listed
+here, it is fair to seek clarification of questions raised in
+Documentation/maintainer/maintainer-entry-profile.rst.
+
+For maintainers, consider documenting additional requirements and
+expectations if submissions routinely overlook specific submission
+criteria. See Documentation/maintainer/maintainer-entry-profile.rst.
+
Contents:
.. toctree::
:numbered:
:maxdepth: 2
+ maintainer-kvm-x86
maintainer-netdev
maintainer-soc
maintainer-soc-clean-dts
+ maintainer-soc-clean-dts
maintainer-tip
- maintainer-kvm-x86
+ ../arch/riscv/patch-acceptance
+ ../doc-guide/maintainer-profile
+ ../driver-api/media/maintainer-entry-profile
+ ../driver-api/vfio-pci-device-specific-driver-acceptance
+ ../filesystems/nfs/nfsd-maintainer-entry-profile
+ ../filesystems/xfs/xfs-maintainer-entry-profile
+ ../mm/damon/maintainer-profile
+ ../nvdimm/maintainer-entry-profile
+ ../nvme/feature-and-quirk-policy
^ permalink raw reply related
* Re: maintainer profiles
From: Jonathan Corbet @ 2026-04-13 19:03 UTC (permalink / raw)
To: Randy Dunlap, Linux Documentation, Linux Kernel Mailing List
Cc: Linux Kernel Workflows
In-Reply-To: <b7775383-da94-4098-8af9-2f672c4f1a71@infradead.org>
Randy Dunlap <rdunlap@infradead.org> writes:
> 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?
Late to the party, sorry ... the original idea, I believe, was that
maintainer-handbooks.rst would be for developers looking for a guidebook
for a specific subsystem, while maintainer-entry-profile.rst was about
how maintainers themselves should write their subsystem guide.
Doubtless things have drifted since then... But the intended audiences
were different, so it might be good to think about bringing them back
into focus.
jon
^ permalink raw reply
* [PATCH 2/2] Documentation/process: maintainer-soc: Document purpose of defconfigs
From: Krzysztof Kozlowski @ 2026-04-13 7:44 UTC (permalink / raw)
To: Arnd Bergmann, Krzysztof Kozlowski, Alexandre Belloni,
Linus Walleij, Drew Fustini, Jonathan Corbet, Shuah Khan,
linux-arm-kernel, soc, workflows, linux-doc, linux-kernel
Cc: Krzysztof Kozlowski
In-Reply-To: <20260413074401.27282-3-krzysztof.kozlowski@oss.qualcomm.com>
Common mistake in commit messages of patches on mailing list adding
CONFIG options to arm/multi_v7 or arm64/defconfig is saying what that
patch is doing, e.g. "Enable driver foo". That is obvious from the diff
part, thus explaining it does not bring any value. What brings value is
to understand why "driver foo" should be in a shared, upstream
defconfig, especially considering that distros have their own defconfigs
and we do not care about non-upstream trees.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/process/maintainer-soc.rst | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
index 4029dc6938d8..a3a90a7d4c68 100644
--- a/Documentation/process/maintainer-soc.rst
+++ b/Documentation/process/maintainer-soc.rst
@@ -207,3 +207,13 @@ The subject line of a pull request should begin with "[GIT PULL]" and made using
a signed tag, rather than a branch. This tag should contain a short description
summarising the changes in the pull request. For more detail on sending pull
requests, please see Documentation/maintainer/pull-requests.rst.
+
+Defconfigs purpose
+~~~~~~~~~~~~~~~~~~
+
+Defconfigs are primarily used by the kernel developers, because distros have
+their own configs. A change adding new CONFIG options to a defconfig should
+explain why the kernel developers in general would want such option, e.g. by
+providing a name of an upstream-supported machine/board using that new option.
+This implies that enabling options in defconfig for non-upstream machines shall
+not be accepted.
--
2.51.0
^ permalink raw reply related
* [PATCH 1/2] Documentation/process: maintainer-soc: Trim from trivial ask-DT
From: Krzysztof Kozlowski @ 2026-04-13 7:44 UTC (permalink / raw)
To: Arnd Bergmann, Krzysztof Kozlowski, Alexandre Belloni,
Linus Walleij, Drew Fustini, Jonathan Corbet, Shuah Khan,
linux-arm-kernel, soc, workflows, linux-doc, linux-kernel
Cc: Krzysztof Kozlowski
It is obvious that one can ask DT maintainers of something, just like
one can ask anyone, so just drop the sentence. Concise documents with
rules have bigger chances of actually being read by people.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Documentation/process/maintainer-soc.rst | 2 --
1 file changed, 2 deletions(-)
diff --git a/Documentation/process/maintainer-soc.rst b/Documentation/process/maintainer-soc.rst
index 7d6bad989ad8..4029dc6938d8 100644
--- a/Documentation/process/maintainer-soc.rst
+++ b/Documentation/process/maintainer-soc.rst
@@ -169,8 +169,6 @@ more information on the validation of devicetrees.
For new platforms, or additions to existing ones, ``make dtbs_check`` should not
add any new warnings. For RISC-V and Samsung SoC, ``make dtbs_check W=1`` is
required to not add any new warnings.
-If in any doubt about a devicetree change, reach out to the devicetree
-maintainers.
Branches and Pull Requests
~~~~~~~~~~~~~~~~~~~~~~~~~~
--
2.51.0
^ permalink raw reply related
* Re: [PATCH net] netrom: do some basic forms of validation on incoming frames
From: Jakub Kicinski @ 2026-04-12 14:41 UTC (permalink / raw)
To: Craig
Cc: hugh, Kuniyuki Iwashima, davem, edumazet, gregkh, horms,
linux-hams, linux-kernel, netdev, pabeni, stable, workflows,
yizhe
In-Reply-To: <761f83cc-58eb-4b4a-ba91-d11412e7b2a6@gmail.com>
On Fri, 10 Apr 2026 15:51:39 -0700 Craig wrote:
> If you're sure the Internet will never fail, I guess it makes
> sense removing all of this since it's inconvenient to maintain.
I did a sweep thru the fixes on Friday, there are 4 more patches
for ham radio pending review. Go ahead and review those.
^ permalink raw reply
* Re: [PATCH net] netrom: do some basic forms of validation on incoming frames
From: Chris Maness @ 2026-04-12 12:56 UTC (permalink / raw)
To: hugh
Cc: Greg KH, Kuniyuki Iwashima, kuba, davem, edumazet, horms,
linux-hams, linux-kernel, netdev, pabeni, stable, workflows,
yizhe
In-Reply-To: <3cd91fbc-d3a9-431e-b915-58e851c7df9f@blemings.org>
Thanks for your work, Hugh.
-73 de Chris KQ6UP
On Sat, Apr 11, 2026 at 7:33 PM Hugh Blemings <hugh@blemings.org> wrote:
>
>
> On 11/4/2026 18:58, Greg KH wrote:
> > On Sat, Apr 11, 2026 at 05:24:17PM +1000, Hugh Blemings wrote:
> >> On 11/4/2026 15:50, Greg KH wrote:
> >>> On Sat, Apr 11, 2026 at 08:25:19AM +1000, Hugh Blemings wrote:
> >>>> On 11/4/2026 08:11, Kuniyuki Iwashima wrote:
> >>>>> From: Jakub Kicinski <kuba@kernel.org>
> >>>>> Date: Fri, 10 Apr 2026 14:54:48 -0700
> >>>>>> On Fri, 10 Apr 2026 14:30:42 -0700 Jakub Kicinski wrote:
> >>>>>>> On Fri, 10 Apr 2026 07:24:36 +0200 Greg Kroah-Hartman wrote:
> >>>>>>>> On Thu, Apr 09, 2026 at 08:32:35PM -0700, Jakub Kicinski wrote:
> >>>>>>>>> Or for simplicity we could also be testing against skb_headlen()
> >>>>>>>>> since we don't expect any legit non-linear frames here? Dunno.
> >>>>>>>> I'll be glad to change this either way, your call. Given that this is
> >>>>>>>> an obsolete protocol that seems to only be a target for drive-by fuzzers
> >>>>>>>> to attack, whatever the simplest thing to do to quiet them up I'll be
> >>>>>>>> glad to implement.
> >>>>>>>>
> >>>>>>>> Or can we just delete this stuff entirely? :)
> >>>>>>> Yes.
> >>>>>>>
> >>>>>>> My thinking is to delete hamradio, nfc, atm, caif.. [more to come]
> >>>>>>> Create GH repos which provide them as OOT modules.
> >>>>>>> Hopefully we can convince any existing users to switch to that.
> >>>>>>>
> >>>>>>> The only thing stopping me is the concern that this is just the softest
> >>>>>>> target and the LLMs will find something else to focus on which we can't
> >>>>>>> delete. I suspect any PCIe driver can be flooded with "aren't you
> >>>>>>> trusting the HW to provide valid responses here?" bullshit.
> >>>>>>>
> >>>>>>> But hey, let's try. I'll post a patch nuking all of hamradio later
> >>>>>>> today.
> >>>>>> Well, either we "expunge" this code to OOT repos, or we mark it
> >>>>>> as broken and tell everyone that we don't take security fixes
> >>>>>> for anything that depends on BROKEN. I'd personally rather expunge.
> >>>>> +1 for "expunge" to prevent LLM-based patch flood.
> >>>>>
> >>>>> IIRC, we did that recently for one driver only used by OpenWRT ?
> >>>>>
> >>>>>
> >>>> If the main concern here is ongoing maintenance of these Ham Radio related
> >>>> protocols/drivers, can we pause for a moment on anything as dramatic as
> >>>> removing from the tree entirely ?
> >>> Sure, but:
> >>>
> >>>> There is a good cohort of capable kernel folks that either are or were ham
> >>>> radio operators who I believe, upon realising that things have got to this
> >>>> point, will be happy to redouble efforts to ensure this code maintained and
> >>>> tested to a satisfactory standard.
> >>> We need this code to be maintained, because as is being shown, there are
> >>> reported problems with it that will affect these devices/networks that
> >>> you all are using. So all we need is a maintainer for this to be able
> >>> to take reports that we get and fix things up as needed. I know you
> >>> have that experience, want to come back to kernel development, we've
> >>> missed you :)
> >> That's most kind Greg, thank you, have missed all you cool kids too :)
> >>
> >> More seriously though - I'd be up for doing it, but I think there may be
> >> others better placed than I who haven't yet realised we have this conundrum.
> >> I'm nudging a few folks offline on this front.
> > The main "conundrum" is, is that this protocol completly trusts the
> > hardware to give the kernel the "correct" data. So if you trust the
> > hardware to work properly, it will be fine, but as the fuzzing tools are
> > finding, if the data from the hardware modems is a bit out-of-spec,
> > "bad" things can happen.
> >
> > I don't know how well controlled the data is from these devices, if it's
> > just a "pass through" from what they get off the "wire" or if the
> > devices always ensure the protocol packets are sane before passing them
> > off to the kernel. That's going to be something you all with the
> > hardware is going to have to determine in order to keep this a working
> > system over time. Especially given that this is a wireless protcol
> > where you "have" to trust the remote end.
>
> Thanks for the thoughts Greg - and ya, I guess on balance I come back to
> being generally skeptical of both hardware and software to Do The Right
> Thing (TM)
>
> So bounds checking and the like seems prudent irrespective of whether
> the kernel is getting the data from real hardware, software modems etc.
>
> I've done some initial digging around that confirms my suspicion that
> this in kernel code remains quite widely used, if somewhat out of view.
> Accordingly I lean then towards working to get these various mitigations
> in place with some revised patches etc. as needed and into the main tree.
>
> Once this done I think that'll give me a good sense of whether I or
> someone else is well positioned to keep the code maintained longer term
> and thus justify it remaining in tree or not.
>
> More to follow once I finish remembering this kernel thing!
>
> Cheers,
> Hugh
>
>
>
>
--
Thanks,
Chris Maness
^ permalink raw reply
* Re: maintainer profiles
From: Mauro Carvalho Chehab @ 2026-04-12 6:31 UTC (permalink / raw)
To: Randy Dunlap
Cc: Linux Documentation, Linux Kernel Mailing List, Jonathan Corbet,
Linux Kernel Workflows, Dan Williams, Thomas Gleixner
In-Reply-To: <a7421a41-458a-4925-a804-e31e2552c79e@infradead.org>
On Sat, 11 Apr 2026 17:02:56 -0700
Randy Dunlap <rdunlap@infradead.org> wrote:
> On 4/11/26 4:54 PM, Randy Dunlap wrote:
> > Hi,
> >
> > On 4/10/26 1:12 AM, Mauro Carvalho Chehab wrote:
> >> On Thu, 9 Apr 2026 17:18:39 -0700
> >> Randy Dunlap <rdunlap@infradead.org> wrote:
> >>
> >>> 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?
> >>
> >> Heh, from the 5 entries at maintainer-handbooks.rst:
> >>
> >> maintainer-netdev
> >> maintainer-soc
> >> maintainer-soc-clean-dts
> >> maintainer-tip
> >> maintainer-kvm-x86
> >>
> >> we have 3 of them already there at maintainer-entry-profile.rst:
> >>
> >> $ grep process/ Documentation/maintainer/maintainer-entry-profile.rst
> >> ../process/maintainer-soc
> >> ../process/maintainer-soc-clean-dts
> >> ../process/maintainer-netdev
> >>
> >> It sounds to me that moving maintainer-tip and maintainer-kvm-x86
> >> to maintainer-entry-profile.rst would be enough to drop
> >> maintainer-handbooks.rst, keeping them consolidated on a single
> >> place.
> >
> > Yes, maybe. How about in the other direction:
> > move them all to maintainer-handbooks.rst?
> >
> > After all, maintainer-entry-profile.rst says:
> > For now, existing maintainer profiles are listed here; we will likely want
> > to do something different in the near future.
(added Don and Thomas to the thread)
I don't have strong preferences, but the maintainer-entry-profile.rst
contains a "default" maintainership model, so, whatever file name,
I would preserve at least most of its contents somewhere.
Probably a more important discussions is where they should would
sit:
- at Documentation/process;
- at Documentation/maintainer;
Another option would be to move the contents from/two those two
books.
> >
> > Also, does anyone know why some of these profiles are numbered and some
> > are not? See
> > https://docs.kernel.org/maintainer/maintainer-entry-profile.html#existing-profiles
> > for odd numbering.
>
> Because they are numbered in their own respective documentation areas...
>
Yes: they're actually links to other places:
.. toctree::
:maxdepth: 1
../doc-guide/maintainer-profile
../nvdimm/maintainer-entry-profile
../arch/riscv/patch-acceptance
../process/maintainer-soc
../process/maintainer-soc-clean-dts
../driver-api/media/maintainer-entry-profile
../process/maintainer-netdev
../driver-api/vfio-pci-device-specific-driver-acceptance
../nvme/feature-and-quirk-policy
../filesystems/nfs/nfsd-maintainer-entry-profile
../filesystems/xfs/xfs-maintainer-entry-profile
../mm/damon/maintainer-profile
On most cases, the profile is located together with other
subsystem-specific docs, as it makes easier to maintain there,
together with other documents from a given subsystem.
It also saves the need to add extra entries at MAINTAINERS
file.
Thanks,
Mauro
^ permalink raw reply
* Re: [PATCH net] netrom: do some basic forms of validation on incoming frames
From: Hugh Blemings @ 2026-04-12 2:32 UTC (permalink / raw)
To: Greg KH
Cc: Kuniyuki Iwashima, kuba, davem, edumazet, horms, linux-hams,
linux-kernel, netdev, pabeni, stable, workflows, yizhe
In-Reply-To: <2026041124-hyphen-circulate-34ae@gregkh>
On 11/4/2026 18:58, Greg KH wrote:
> On Sat, Apr 11, 2026 at 05:24:17PM +1000, Hugh Blemings wrote:
>> On 11/4/2026 15:50, Greg KH wrote:
>>> On Sat, Apr 11, 2026 at 08:25:19AM +1000, Hugh Blemings wrote:
>>>> On 11/4/2026 08:11, Kuniyuki Iwashima wrote:
>>>>> From: Jakub Kicinski <kuba@kernel.org>
>>>>> Date: Fri, 10 Apr 2026 14:54:48 -0700
>>>>>> On Fri, 10 Apr 2026 14:30:42 -0700 Jakub Kicinski wrote:
>>>>>>> On Fri, 10 Apr 2026 07:24:36 +0200 Greg Kroah-Hartman wrote:
>>>>>>>> On Thu, Apr 09, 2026 at 08:32:35PM -0700, Jakub Kicinski wrote:
>>>>>>>>> Or for simplicity we could also be testing against skb_headlen()
>>>>>>>>> since we don't expect any legit non-linear frames here? Dunno.
>>>>>>>> I'll be glad to change this either way, your call. Given that this is
>>>>>>>> an obsolete protocol that seems to only be a target for drive-by fuzzers
>>>>>>>> to attack, whatever the simplest thing to do to quiet them up I'll be
>>>>>>>> glad to implement.
>>>>>>>>
>>>>>>>> Or can we just delete this stuff entirely? :)
>>>>>>> Yes.
>>>>>>>
>>>>>>> My thinking is to delete hamradio, nfc, atm, caif.. [more to come]
>>>>>>> Create GH repos which provide them as OOT modules.
>>>>>>> Hopefully we can convince any existing users to switch to that.
>>>>>>>
>>>>>>> The only thing stopping me is the concern that this is just the softest
>>>>>>> target and the LLMs will find something else to focus on which we can't
>>>>>>> delete. I suspect any PCIe driver can be flooded with "aren't you
>>>>>>> trusting the HW to provide valid responses here?" bullshit.
>>>>>>>
>>>>>>> But hey, let's try. I'll post a patch nuking all of hamradio later
>>>>>>> today.
>>>>>> Well, either we "expunge" this code to OOT repos, or we mark it
>>>>>> as broken and tell everyone that we don't take security fixes
>>>>>> for anything that depends on BROKEN. I'd personally rather expunge.
>>>>> +1 for "expunge" to prevent LLM-based patch flood.
>>>>>
>>>>> IIRC, we did that recently for one driver only used by OpenWRT ?
>>>>>
>>>>>
>>>> If the main concern here is ongoing maintenance of these Ham Radio related
>>>> protocols/drivers, can we pause for a moment on anything as dramatic as
>>>> removing from the tree entirely ?
>>> Sure, but:
>>>
>>>> There is a good cohort of capable kernel folks that either are or were ham
>>>> radio operators who I believe, upon realising that things have got to this
>>>> point, will be happy to redouble efforts to ensure this code maintained and
>>>> tested to a satisfactory standard.
>>> We need this code to be maintained, because as is being shown, there are
>>> reported problems with it that will affect these devices/networks that
>>> you all are using. So all we need is a maintainer for this to be able
>>> to take reports that we get and fix things up as needed. I know you
>>> have that experience, want to come back to kernel development, we've
>>> missed you :)
>> That's most kind Greg, thank you, have missed all you cool kids too :)
>>
>> More seriously though - I'd be up for doing it, but I think there may be
>> others better placed than I who haven't yet realised we have this conundrum.
>> I'm nudging a few folks offline on this front.
> The main "conundrum" is, is that this protocol completly trusts the
> hardware to give the kernel the "correct" data. So if you trust the
> hardware to work properly, it will be fine, but as the fuzzing tools are
> finding, if the data from the hardware modems is a bit out-of-spec,
> "bad" things can happen.
>
> I don't know how well controlled the data is from these devices, if it's
> just a "pass through" from what they get off the "wire" or if the
> devices always ensure the protocol packets are sane before passing them
> off to the kernel. That's going to be something you all with the
> hardware is going to have to determine in order to keep this a working
> system over time. Especially given that this is a wireless protcol
> where you "have" to trust the remote end.
Thanks for the thoughts Greg - and ya, I guess on balance I come back to
being generally skeptical of both hardware and software to Do The Right
Thing (TM)
So bounds checking and the like seems prudent irrespective of whether
the kernel is getting the data from real hardware, software modems etc.
I've done some initial digging around that confirms my suspicion that
this in kernel code remains quite widely used, if somewhat out of view.
Accordingly I lean then towards working to get these various mitigations
in place with some revised patches etc. as needed and into the main tree.
Once this done I think that'll give me a good sense of whether I or
someone else is well positioned to keep the code maintained longer term
and thus justify it remaining in tree or not.
More to follow once I finish remembering this kernel thing!
Cheers,
Hugh
^ permalink raw reply
* Re: maintainer profiles
From: Randy Dunlap @ 2026-04-12 0:02 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Documentation, Linux Kernel Mailing List, Jonathan Corbet,
Linux Kernel Workflows
In-Reply-To: <d8804a85-dd2b-481e-903f-c6fea5d24c97@infradead.org>
On 4/11/26 4:54 PM, Randy Dunlap wrote:
> Hi,
>
> On 4/10/26 1:12 AM, Mauro Carvalho Chehab wrote:
>> On Thu, 9 Apr 2026 17:18:39 -0700
>> Randy Dunlap <rdunlap@infradead.org> wrote:
>>
>>> 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?
>>
>> Heh, from the 5 entries at maintainer-handbooks.rst:
>>
>> maintainer-netdev
>> maintainer-soc
>> maintainer-soc-clean-dts
>> maintainer-tip
>> maintainer-kvm-x86
>>
>> we have 3 of them already there at maintainer-entry-profile.rst:
>>
>> $ grep process/ Documentation/maintainer/maintainer-entry-profile.rst
>> ../process/maintainer-soc
>> ../process/maintainer-soc-clean-dts
>> ../process/maintainer-netdev
>>
>> It sounds to me that moving maintainer-tip and maintainer-kvm-x86
>> to maintainer-entry-profile.rst would be enough to drop
>> maintainer-handbooks.rst, keeping them consolidated on a single
>> place.
>
> Yes, maybe. How about in the other direction:
> move them all to maintainer-handbooks.rst?
>
> After all, maintainer-entry-profile.rst says:
> For now, existing maintainer profiles are listed here; we will likely want
> to do something different in the near future.
>
> Also, does anyone know why some of these profiles are numbered and some
> are not? See
> https://docs.kernel.org/maintainer/maintainer-entry-profile.html#existing-profiles
> for odd numbering.
Because they are numbered in their own respective documentation areas...
--
~Randy
^ permalink raw reply
* Re: maintainer profiles
From: Randy Dunlap @ 2026-04-11 23:54 UTC (permalink / raw)
To: Mauro Carvalho Chehab
Cc: Linux Documentation, Linux Kernel Mailing List, Jonathan Corbet,
Linux Kernel Workflows
In-Reply-To: <20260410101239.04c87f26@foz.lan>
Hi,
On 4/10/26 1:12 AM, Mauro Carvalho Chehab wrote:
> On Thu, 9 Apr 2026 17:18:39 -0700
> Randy Dunlap <rdunlap@infradead.org> wrote:
>
>> 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?
>
> Heh, from the 5 entries at maintainer-handbooks.rst:
>
> maintainer-netdev
> maintainer-soc
> maintainer-soc-clean-dts
> maintainer-tip
> maintainer-kvm-x86
>
> we have 3 of them already there at maintainer-entry-profile.rst:
>
> $ grep process/ Documentation/maintainer/maintainer-entry-profile.rst
> ../process/maintainer-soc
> ../process/maintainer-soc-clean-dts
> ../process/maintainer-netdev
>
> It sounds to me that moving maintainer-tip and maintainer-kvm-x86
> to maintainer-entry-profile.rst would be enough to drop
> maintainer-handbooks.rst, keeping them consolidated on a single
> place.
Yes, maybe. How about in the other direction:
move them all to maintainer-handbooks.rst?
After all, maintainer-entry-profile.rst says:
For now, existing maintainer profiles are listed here; we will likely want
to do something different in the near future.
Also, does anyone know why some of these profiles are numbered and some
are not? See
https://docs.kernel.org/maintainer/maintainer-entry-profile.html#existing-profiles
for odd numbering.
thanks.
--
~Randy
^ permalink raw reply
* Re: [PATCH net] netrom: do some basic forms of validation on incoming frames
From: Chris Maness @ 2026-04-11 20:33 UTC (permalink / raw)
To: hugh
Cc: Craig, Kuniyuki Iwashima, kuba, davem, edumazet, gregkh, horms,
linux-hams, linux-kernel, netdev, pabeni, stable, workflows,
yizhe
In-Reply-To: <CANnsUMEniMzLnp5h=Gz83=Wcegc-jGz9vqyWyEpWx-OH=Dij1w@mail.gmail.com>
forms of validation on incoming frames
I for one run two BBS’s that use LinFBB. LinFBB uses the kernel code
for its AX.25 stack. This is still excellent software that is
maintained. I also use Linux as a netrom node for said BBS with real
radio ports and internet connectivity to out of town nodes using the
ax25ipd/netromd that both use kernel stacks.
73 de Chris KQ6UP
Thanks,
Chris Maness
Thanks,
Chris Maness
-Sent from my iPhone
On Fri, Apr 10, 2026 at 4:53 PM Chris Maness
<christopher.maness@gmail.com> wrote:
>
> I for one run two BBS’s that use LinFBB. LinFBB uses the kernel code for its AX.25 stack. This is still excellent software that is maintained. I also use Linux as a netrom node for said BBS with real radio ports and internet connectivity to out of town nodes using the ax25ipd/netromd that both use kernel stacks.
>
> 73 de Chris KQ6UP
>
> Thanks,
> Chris Maness
> -Sent from my iPhone
>
>
> On Fri, Apr 10, 2026 at 4:38 PM Hugh Blemings <hugh@blemings.org> wrote:
>>
>>
>> On 11/4/2026 08:51, Craig wrote:
>> >> If the main concern here is ongoing maintenance of these Ham Radio
>> >> related protocols/drivers, can we pause for a moment on anything as
>> >> dramatic as removing from the tree entirely ?
>> >>
>> >> There is a good cohort of capable kernel folks that either are or
>> >> were ham radio operators who I believe, upon realising that things
>> >> have got to this point, will be happy to redouble efforts to ensure
>> >> this code maintained and tested to a satisfactory standard.
>> >>
>> >> Or, alternatively, as a technical community it may be that the Ham
>> >> Radio interested folks conclude that out of tree or user space
>> >> solutions are a better way forward as others have proposed.
>> >>
>> >> Give us a few days, please, for the word to be put around that we
>> >> need to pull ourselves together a bit as a technical group :)
>> >>
>> >
>> > I, for one, really can't imagine pulling an entire network subsytem
>> > out of the kernel without any
>> > knowledge of how/if/when it's used. Like intercontinental radio
>> > networks, global email, ax.25
>> > keyboard-to-keyboard, BBS and other emergency-communication systems
>> > throughout the
>> > world. If you're sure the Internet will never fail, I guess it makes
>> > sense removing all of this
>> > since it's inconvenient to maintain.
>> >
>> > Global AX.25 keyboard-to-keyboard on 14.105Mhz
>> >
>> > https://qsl.net/kb9pvh/105.html
>> >
>> > AX.25/netrom VHF routed networks spanning from Oregon to Los Angeles.
>> >
>> > https://www.easymapmaker.com/map/80666c4898ec6e8fa0c35add5d03282d
>> >
>> > Global radio email using AX.25
>> >
>> > https://winlink.org/RMSChannels (1,336 AX.25 email packet nodes on
>> > the Earth and Space)
>> >
>> > This is all in operation by Amateur Radio ARES emergency
>> > protocols/technologies. This
>> > will not pass the headline test when it comes to Linux detractors.
>> >
>> > Most of this is running on Raspberry Pi / Linux 24/7.
>> >
>> > If we want to kill all these apps and somehow force them into user space,
>> > it's akin to just switching to Windows - and flounder with the
>> > Microsoft folks
>> > trying to do the same thing.
>>
>> Your email Craig neatly encapsulates just some of the practical and
>> ongoing applications of the kernel code in question - I don't think this
>> is in dispute.
>>
>> What's pertinent is if we as the ham/amatuer radio community can agree
>> on whether in tree, out of tree modules, or a userspace device driver
>> approach make the most sense. If we are to keep code in the kernel in
>> any form, we as a community need to find someone(s) that have the skills
>> and bandwidth to keep the in tree code up to date.
>>
>> I don't think this would be onerous and I have a couple of people in
>> mind to nudge who may be happy to do so if that proves the right way
>> forward. At a pinch I could do it, but that'll mean a lot of catching
>> up. But I think it reasonable that the responsibility here falls to
>> folks that are closer to the code in question than the wider and
>> overworked kernel maintainer community.
>>
>> That said, I think Dan Cross (KZ2X) earlier email makes a pretty strong
>> case for moving out of the kernel while still providing a way to have
>> backward compatibility, perhaps this might be the way forward?
>>
>> In any case, done well, this approach would not kill the apps or force
>> anything like switching to Windows! :) Great projects like digipi would
>> be able to continue with minimal changes.
>>
>> I wonder if a separate thread in linux-hams makes sense to discuss the
>> various longer term approaches to maintaining these capabilities - I'll
>> try make time later today to kick one off - such deliberations will be
>> of less interest to the broader LKML and other lists.
>>
>> Cheers/73
>> Hugh
>>
>>
>>
>> >
>> >
>> > -craig
>> > https://digipi.org/
>> >
>> >
>> --
>> I am slowly moving to hugh@blemings.id.au as my main email address.
>> If you're using hugh@blemings.org please update your address book accordingly.
>> Thank you :)
>>
>>
--
Thanks,
Chris Maness
^ permalink raw reply
* Re: [PATCH net] netrom: do some basic forms of validation on incoming frames
From: Greg KH @ 2026-04-11 8:58 UTC (permalink / raw)
To: hugh
Cc: Kuniyuki Iwashima, kuba, davem, edumazet, horms, linux-hams,
linux-kernel, netdev, pabeni, stable, workflows, yizhe
In-Reply-To: <b9355e3c-9252-4dd7-b7ed-dff13e3b2c8b@blemings.org>
On Sat, Apr 11, 2026 at 05:24:17PM +1000, Hugh Blemings wrote:
>
> On 11/4/2026 15:50, Greg KH wrote:
> > On Sat, Apr 11, 2026 at 08:25:19AM +1000, Hugh Blemings wrote:
> > > On 11/4/2026 08:11, Kuniyuki Iwashima wrote:
> > > > From: Jakub Kicinski <kuba@kernel.org>
> > > > Date: Fri, 10 Apr 2026 14:54:48 -0700
> > > > > On Fri, 10 Apr 2026 14:30:42 -0700 Jakub Kicinski wrote:
> > > > > > On Fri, 10 Apr 2026 07:24:36 +0200 Greg Kroah-Hartman wrote:
> > > > > > > On Thu, Apr 09, 2026 at 08:32:35PM -0700, Jakub Kicinski wrote:
> > > > > > > > Or for simplicity we could also be testing against skb_headlen()
> > > > > > > > since we don't expect any legit non-linear frames here? Dunno.
> > > > > > > I'll be glad to change this either way, your call. Given that this is
> > > > > > > an obsolete protocol that seems to only be a target for drive-by fuzzers
> > > > > > > to attack, whatever the simplest thing to do to quiet them up I'll be
> > > > > > > glad to implement.
> > > > > > >
> > > > > > > Or can we just delete this stuff entirely? :)
> > > > > > Yes.
> > > > > >
> > > > > > My thinking is to delete hamradio, nfc, atm, caif.. [more to come]
> > > > > > Create GH repos which provide them as OOT modules.
> > > > > > Hopefully we can convince any existing users to switch to that.
> > > > > >
> > > > > > The only thing stopping me is the concern that this is just the softest
> > > > > > target and the LLMs will find something else to focus on which we can't
> > > > > > delete. I suspect any PCIe driver can be flooded with "aren't you
> > > > > > trusting the HW to provide valid responses here?" bullshit.
> > > > > >
> > > > > > But hey, let's try. I'll post a patch nuking all of hamradio later
> > > > > > today.
> > > > > Well, either we "expunge" this code to OOT repos, or we mark it
> > > > > as broken and tell everyone that we don't take security fixes
> > > > > for anything that depends on BROKEN. I'd personally rather expunge.
> > > > +1 for "expunge" to prevent LLM-based patch flood.
> > > >
> > > > IIRC, we did that recently for one driver only used by OpenWRT ?
> > > >
> > > >
> > > If the main concern here is ongoing maintenance of these Ham Radio related
> > > protocols/drivers, can we pause for a moment on anything as dramatic as
> > > removing from the tree entirely ?
> > Sure, but:
> >
> > > There is a good cohort of capable kernel folks that either are or were ham
> > > radio operators who I believe, upon realising that things have got to this
> > > point, will be happy to redouble efforts to ensure this code maintained and
> > > tested to a satisfactory standard.
> > We need this code to be maintained, because as is being shown, there are
> > reported problems with it that will affect these devices/networks that
> > you all are using. So all we need is a maintainer for this to be able
> > to take reports that we get and fix things up as needed. I know you
> > have that experience, want to come back to kernel development, we've
> > missed you :)
>
> That's most kind Greg, thank you, have missed all you cool kids too :)
>
> More seriously though - I'd be up for doing it, but I think there may be
> others better placed than I who haven't yet realised we have this conundrum.
> I'm nudging a few folks offline on this front.
The main "conundrum" is, is that this protocol completly trusts the
hardware to give the kernel the "correct" data. So if you trust the
hardware to work properly, it will be fine, but as the fuzzing tools are
finding, if the data from the hardware modems is a bit out-of-spec,
"bad" things can happen.
I don't know how well controlled the data is from these devices, if it's
just a "pass through" from what they get off the "wire" or if the
devices always ensure the protocol packets are sane before passing them
off to the kernel. That's going to be something you all with the
hardware is going to have to determine in order to keep this a working
system over time. Especially given that this is a wireless protcol
where you "have" to trust the remote end.
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net] netrom: do some basic forms of validation on incoming frames
From: Hugh Blemings @ 2026-04-11 7:24 UTC (permalink / raw)
To: Greg KH, hugh
Cc: Kuniyuki Iwashima, kuba, davem, edumazet, horms, linux-hams,
linux-kernel, netdev, pabeni, stable, workflows, yizhe
In-Reply-To: <2026041135-shindig-trekker-5d06@gregkh>
On 11/4/2026 15:50, Greg KH wrote:
> On Sat, Apr 11, 2026 at 08:25:19AM +1000, Hugh Blemings wrote:
>> On 11/4/2026 08:11, Kuniyuki Iwashima wrote:
>>> From: Jakub Kicinski <kuba@kernel.org>
>>> Date: Fri, 10 Apr 2026 14:54:48 -0700
>>>> On Fri, 10 Apr 2026 14:30:42 -0700 Jakub Kicinski wrote:
>>>>> On Fri, 10 Apr 2026 07:24:36 +0200 Greg Kroah-Hartman wrote:
>>>>>> On Thu, Apr 09, 2026 at 08:32:35PM -0700, Jakub Kicinski wrote:
>>>>>>> Or for simplicity we could also be testing against skb_headlen()
>>>>>>> since we don't expect any legit non-linear frames here? Dunno.
>>>>>> I'll be glad to change this either way, your call. Given that this is
>>>>>> an obsolete protocol that seems to only be a target for drive-by fuzzers
>>>>>> to attack, whatever the simplest thing to do to quiet them up I'll be
>>>>>> glad to implement.
>>>>>>
>>>>>> Or can we just delete this stuff entirely? :)
>>>>> Yes.
>>>>>
>>>>> My thinking is to delete hamradio, nfc, atm, caif.. [more to come]
>>>>> Create GH repos which provide them as OOT modules.
>>>>> Hopefully we can convince any existing users to switch to that.
>>>>>
>>>>> The only thing stopping me is the concern that this is just the softest
>>>>> target and the LLMs will find something else to focus on which we can't
>>>>> delete. I suspect any PCIe driver can be flooded with "aren't you
>>>>> trusting the HW to provide valid responses here?" bullshit.
>>>>>
>>>>> But hey, let's try. I'll post a patch nuking all of hamradio later
>>>>> today.
>>>> Well, either we "expunge" this code to OOT repos, or we mark it
>>>> as broken and tell everyone that we don't take security fixes
>>>> for anything that depends on BROKEN. I'd personally rather expunge.
>>> +1 for "expunge" to prevent LLM-based patch flood.
>>>
>>> IIRC, we did that recently for one driver only used by OpenWRT ?
>>>
>>>
>> If the main concern here is ongoing maintenance of these Ham Radio related
>> protocols/drivers, can we pause for a moment on anything as dramatic as
>> removing from the tree entirely ?
> Sure, but:
>
>> There is a good cohort of capable kernel folks that either are or were ham
>> radio operators who I believe, upon realising that things have got to this
>> point, will be happy to redouble efforts to ensure this code maintained and
>> tested to a satisfactory standard.
> We need this code to be maintained, because as is being shown, there are
> reported problems with it that will affect these devices/networks that
> you all are using. So all we need is a maintainer for this to be able
> to take reports that we get and fix things up as needed. I know you
> have that experience, want to come back to kernel development, we've
> missed you :)
That's most kind Greg, thank you, have missed all you cool kids too :)
More seriously though - I'd be up for doing it, but I think there may be
others better placed than I who haven't yet realised we have this
conundrum. I'm nudging a few folks offline on this front.
I've also kicked off a thread in linux-hams to discuss some of the
broader questions raised about staying in tree, going to out of tree or
looking at userspace solutions instead.
We'll try get a cohesive picture back over next few days.
Cheers,
Hugh
--
I am slowly moving to hugh@blemings.id.au as my main email address.
If you're using hugh@blemings.org please update your address book accordingly.
Thank you :)
^ permalink raw reply
* Re: [PATCH net] netrom: do some basic forms of validation on incoming frames
From: Greg KH @ 2026-04-11 5:50 UTC (permalink / raw)
To: hugh
Cc: Kuniyuki Iwashima, kuba, davem, edumazet, horms, linux-hams,
linux-kernel, netdev, pabeni, stable, workflows, yizhe
In-Reply-To: <4f5810a7-c792-4d6b-9f7c-6c6b289def19@blemings.org>
On Sat, Apr 11, 2026 at 08:25:19AM +1000, Hugh Blemings wrote:
>
> On 11/4/2026 08:11, Kuniyuki Iwashima wrote:
> > From: Jakub Kicinski <kuba@kernel.org>
> > Date: Fri, 10 Apr 2026 14:54:48 -0700
> > > On Fri, 10 Apr 2026 14:30:42 -0700 Jakub Kicinski wrote:
> > > > On Fri, 10 Apr 2026 07:24:36 +0200 Greg Kroah-Hartman wrote:
> > > > > On Thu, Apr 09, 2026 at 08:32:35PM -0700, Jakub Kicinski wrote:
> > > > > > Or for simplicity we could also be testing against skb_headlen()
> > > > > > since we don't expect any legit non-linear frames here? Dunno.
> > > > > I'll be glad to change this either way, your call. Given that this is
> > > > > an obsolete protocol that seems to only be a target for drive-by fuzzers
> > > > > to attack, whatever the simplest thing to do to quiet them up I'll be
> > > > > glad to implement.
> > > > >
> > > > > Or can we just delete this stuff entirely? :)
> > > > Yes.
> > > >
> > > > My thinking is to delete hamradio, nfc, atm, caif.. [more to come]
> > > > Create GH repos which provide them as OOT modules.
> > > > Hopefully we can convince any existing users to switch to that.
> > > >
> > > > The only thing stopping me is the concern that this is just the softest
> > > > target and the LLMs will find something else to focus on which we can't
> > > > delete. I suspect any PCIe driver can be flooded with "aren't you
> > > > trusting the HW to provide valid responses here?" bullshit.
> > > >
> > > > But hey, let's try. I'll post a patch nuking all of hamradio later
> > > > today.
> > > Well, either we "expunge" this code to OOT repos, or we mark it
> > > as broken and tell everyone that we don't take security fixes
> > > for anything that depends on BROKEN. I'd personally rather expunge.
> > +1 for "expunge" to prevent LLM-based patch flood.
> >
> > IIRC, we did that recently for one driver only used by OpenWRT ?
> >
> >
> If the main concern here is ongoing maintenance of these Ham Radio related
> protocols/drivers, can we pause for a moment on anything as dramatic as
> removing from the tree entirely ?
Sure, but:
> There is a good cohort of capable kernel folks that either are or were ham
> radio operators who I believe, upon realising that things have got to this
> point, will be happy to redouble efforts to ensure this code maintained and
> tested to a satisfactory standard.
We need this code to be maintained, because as is being shown, there are
reported problems with it that will affect these devices/networks that
you all are using. So all we need is a maintainer for this to be able
to take reports that we get and fix things up as needed. I know you
have that experience, want to come back to kernel development, we've
missed you :)
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH net] netrom: do some basic forms of validation on incoming frames
From: Hugh Blemings @ 2026-04-10 23:38 UTC (permalink / raw)
To: Craig, hugh, Kuniyuki Iwashima, kuba
Cc: davem, edumazet, gregkh, horms, linux-hams, linux-kernel, netdev,
pabeni, stable, workflows, yizhe
In-Reply-To: <761f83cc-58eb-4b4a-ba91-d11412e7b2a6@gmail.com>
On 11/4/2026 08:51, Craig wrote:
>> If the main concern here is ongoing maintenance of these Ham Radio
>> related protocols/drivers, can we pause for a moment on anything as
>> dramatic as removing from the tree entirely ?
>>
>> There is a good cohort of capable kernel folks that either are or
>> were ham radio operators who I believe, upon realising that things
>> have got to this point, will be happy to redouble efforts to ensure
>> this code maintained and tested to a satisfactory standard.
>>
>> Or, alternatively, as a technical community it may be that the Ham
>> Radio interested folks conclude that out of tree or user space
>> solutions are a better way forward as others have proposed.
>>
>> Give us a few days, please, for the word to be put around that we
>> need to pull ourselves together a bit as a technical group :)
>>
>
> I, for one, really can't imagine pulling an entire network subsytem
> out of the kernel without any
> knowledge of how/if/when it's used. Like intercontinental radio
> networks, global email, ax.25
> keyboard-to-keyboard, BBS and other emergency-communication systems
> throughout the
> world. If you're sure the Internet will never fail, I guess it makes
> sense removing all of this
> since it's inconvenient to maintain.
>
> Global AX.25 keyboard-to-keyboard on 14.105Mhz
>
> https://qsl.net/kb9pvh/105.html
>
> AX.25/netrom VHF routed networks spanning from Oregon to Los Angeles.
>
> https://www.easymapmaker.com/map/80666c4898ec6e8fa0c35add5d03282d
>
> Global radio email using AX.25
>
> https://winlink.org/RMSChannels (1,336 AX.25 email packet nodes on
> the Earth and Space)
>
> This is all in operation by Amateur Radio ARES emergency
> protocols/technologies. This
> will not pass the headline test when it comes to Linux detractors.
>
> Most of this is running on Raspberry Pi / Linux 24/7.
>
> If we want to kill all these apps and somehow force them into user space,
> it's akin to just switching to Windows - and flounder with the
> Microsoft folks
> trying to do the same thing.
Your email Craig neatly encapsulates just some of the practical and
ongoing applications of the kernel code in question - I don't think this
is in dispute.
What's pertinent is if we as the ham/amatuer radio community can agree
on whether in tree, out of tree modules, or a userspace device driver
approach make the most sense. If we are to keep code in the kernel in
any form, we as a community need to find someone(s) that have the skills
and bandwidth to keep the in tree code up to date.
I don't think this would be onerous and I have a couple of people in
mind to nudge who may be happy to do so if that proves the right way
forward. At a pinch I could do it, but that'll mean a lot of catching
up. But I think it reasonable that the responsibility here falls to
folks that are closer to the code in question than the wider and
overworked kernel maintainer community.
That said, I think Dan Cross (KZ2X) earlier email makes a pretty strong
case for moving out of the kernel while still providing a way to have
backward compatibility, perhaps this might be the way forward?
In any case, done well, this approach would not kill the apps or force
anything like switching to Windows! :) Great projects like digipi would
be able to continue with minimal changes.
I wonder if a separate thread in linux-hams makes sense to discuss the
various longer term approaches to maintaining these capabilities - I'll
try make time later today to kick one off - such deliberations will be
of less interest to the broader LKML and other lists.
Cheers/73
Hugh
>
>
> -craig
> https://digipi.org/
>
>
--
I am slowly moving to hugh@blemings.id.au as my main email address.
If you're using hugh@blemings.org please update your address book accordingly.
Thank you :)
^ permalink raw reply
* Re: [PATCH net] netrom: do some basic forms of validation on incoming frames
From: Craig @ 2026-04-10 22:51 UTC (permalink / raw)
To: hugh, Kuniyuki Iwashima, kuba
Cc: davem, edumazet, gregkh, horms, linux-hams, linux-kernel, netdev,
pabeni, stable, workflows, yizhe
In-Reply-To: <4f5810a7-c792-4d6b-9f7c-6c6b289def19@blemings.org>
> If the main concern here is ongoing maintenance of these Ham Radio
> related protocols/drivers, can we pause for a moment on anything as
> dramatic as removing from the tree entirely ?
>
> There is a good cohort of capable kernel folks that either are or were
> ham radio operators who I believe, upon realising that things have got
> to this point, will be happy to redouble efforts to ensure this code
> maintained and tested to a satisfactory standard.
>
> Or, alternatively, as a technical community it may be that the Ham
> Radio interested folks conclude that out of tree or user space
> solutions are a better way forward as others have proposed.
>
> Give us a few days, please, for the word to be put around that we need
> to pull ourselves together a bit as a technical group :)
>
I, for one, really can't imagine pulling an entire network subsytem out
of the kernel without any
knowledge of how/if/when it's used. Like intercontinental radio
networks, global email, ax.25
keyboard-to-keyboard, BBS and other emergency-communication systems
throughout the
world. If you're sure the Internet will never fail, I guess it makes
sense removing all of this
since it's inconvenient to maintain.
Global AX.25 keyboard-to-keyboard on 14.105Mhz
https://qsl.net/kb9pvh/105.html
AX.25/netrom VHF routed networks spanning from Oregon to Los Angeles.
https://www.easymapmaker.com/map/80666c4898ec6e8fa0c35add5d03282d
Global radio email using AX.25
https://winlink.org/RMSChannels (1,336 AX.25 email packet nodes on
the Earth and Space)
This is all in operation by Amateur Radio ARES emergency
protocols/technologies. This
will not pass the headline test when it comes to Linux detractors.
Most of this is running on Raspberry Pi / Linux 24/7.
If we want to kill all these apps and somehow force them into user space,
it's akin to just switching to Windows - and flounder with the Microsoft
folks
trying to do the same thing.
-craig
https://digipi.org/
^ permalink raw reply
* Re: [PATCH net] netrom: do some basic forms of validation on incoming frames
From: Hugh Blemings @ 2026-04-10 22:25 UTC (permalink / raw)
To: Kuniyuki Iwashima, kuba
Cc: davem, edumazet, gregkh, horms, linux-hams, linux-kernel, netdev,
pabeni, stable, workflows, yizhe
In-Reply-To: <20260410221220.1708137-1-kuniyu@google.com>
On 11/4/2026 08:11, Kuniyuki Iwashima wrote:
> From: Jakub Kicinski <kuba@kernel.org>
> Date: Fri, 10 Apr 2026 14:54:48 -0700
>> On Fri, 10 Apr 2026 14:30:42 -0700 Jakub Kicinski wrote:
>>> On Fri, 10 Apr 2026 07:24:36 +0200 Greg Kroah-Hartman wrote:
>>>> On Thu, Apr 09, 2026 at 08:32:35PM -0700, Jakub Kicinski wrote:
>>>>> Or for simplicity we could also be testing against skb_headlen()
>>>>> since we don't expect any legit non-linear frames here? Dunno.
>>>> I'll be glad to change this either way, your call. Given that this is
>>>> an obsolete protocol that seems to only be a target for drive-by fuzzers
>>>> to attack, whatever the simplest thing to do to quiet them up I'll be
>>>> glad to implement.
>>>>
>>>> Or can we just delete this stuff entirely? :)
>>> Yes.
>>>
>>> My thinking is to delete hamradio, nfc, atm, caif.. [more to come]
>>> Create GH repos which provide them as OOT modules.
>>> Hopefully we can convince any existing users to switch to that.
>>>
>>> The only thing stopping me is the concern that this is just the softest
>>> target and the LLMs will find something else to focus on which we can't
>>> delete. I suspect any PCIe driver can be flooded with "aren't you
>>> trusting the HW to provide valid responses here?" bullshit.
>>>
>>> But hey, let's try. I'll post a patch nuking all of hamradio later
>>> today.
>> Well, either we "expunge" this code to OOT repos, or we mark it
>> as broken and tell everyone that we don't take security fixes
>> for anything that depends on BROKEN. I'd personally rather expunge.
> +1 for "expunge" to prevent LLM-based patch flood.
>
> IIRC, we did that recently for one driver only used by OpenWRT ?
>
>
If the main concern here is ongoing maintenance of these Ham Radio
related protocols/drivers, can we pause for a moment on anything as
dramatic as removing from the tree entirely ?
There is a good cohort of capable kernel folks that either are or were
ham radio operators who I believe, upon realising that things have got
to this point, will be happy to redouble efforts to ensure this code
maintained and tested to a satisfactory standard.
Or, alternatively, as a technical community it may be that the Ham Radio
interested folks conclude that out of tree or user space solutions are a
better way forward as others have proposed.
Give us a few days, please, for the word to be put around that we need
to pull ourselves together a bit as a technical group :)
Cheers/73
Hugh
VK3YYZ/AD5RV/Lapsed Kernel Maintainer... ;)
>> cc: workflows, we can't be the only ones still nursing Linux 2.2 code
--
I am slowly moving to hugh@blemings.id.au as my main email address.
If you're using hugh@blemings.org please update your address book accordingly.
Thank you :)
^ permalink raw reply
* Re: [PATCH net] netrom: do some basic forms of validation on incoming frames
From: Kuniyuki Iwashima @ 2026-04-10 22:11 UTC (permalink / raw)
To: kuba
Cc: davem, edumazet, gregkh, horms, linux-hams, linux-kernel, netdev,
pabeni, stable, workflows, yizhe
In-Reply-To: <20260410145448.38253e3c@kernel.org>
From: Jakub Kicinski <kuba@kernel.org>
Date: Fri, 10 Apr 2026 14:54:48 -0700
> On Fri, 10 Apr 2026 14:30:42 -0700 Jakub Kicinski wrote:
> > On Fri, 10 Apr 2026 07:24:36 +0200 Greg Kroah-Hartman wrote:
> > > On Thu, Apr 09, 2026 at 08:32:35PM -0700, Jakub Kicinski wrote:
> > > > Or for simplicity we could also be testing against skb_headlen()
> > > > since we don't expect any legit non-linear frames here? Dunno.
> > >
> > > I'll be glad to change this either way, your call. Given that this is
> > > an obsolete protocol that seems to only be a target for drive-by fuzzers
> > > to attack, whatever the simplest thing to do to quiet them up I'll be
> > > glad to implement.
> > >
> > > Or can we just delete this stuff entirely? :)
> >
> > Yes.
> >
> > My thinking is to delete hamradio, nfc, atm, caif.. [more to come]
> > Create GH repos which provide them as OOT modules.
> > Hopefully we can convince any existing users to switch to that.
> >
> > The only thing stopping me is the concern that this is just the softest
> > target and the LLMs will find something else to focus on which we can't
> > delete. I suspect any PCIe driver can be flooded with "aren't you
> > trusting the HW to provide valid responses here?" bullshit.
> >
> > But hey, let's try. I'll post a patch nuking all of hamradio later
> > today.
>
> Well, either we "expunge" this code to OOT repos, or we mark it
> as broken and tell everyone that we don't take security fixes
> for anything that depends on BROKEN. I'd personally rather expunge.
+1 for "expunge" to prevent LLM-based patch flood.
IIRC, we did that recently for one driver only used by OpenWRT ?
>
> cc: workflows, we can't be the only ones still nursing Linux 2.2 code
^ permalink raw reply
* Re: [PATCH net] netrom: do some basic forms of validation on incoming frames
From: Jakub Kicinski @ 2026-04-10 21:54 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Simon Horman, netdev, linux-kernel, David S. Miller, Eric Dumazet,
Paolo Abeni, linux-hams, Yizhe Zhuang, stable, workflows
In-Reply-To: <20260410143042.1d4436de@kernel.org>
On Fri, 10 Apr 2026 14:30:42 -0700 Jakub Kicinski wrote:
> On Fri, 10 Apr 2026 07:24:36 +0200 Greg Kroah-Hartman wrote:
> > On Thu, Apr 09, 2026 at 08:32:35PM -0700, Jakub Kicinski wrote:
> > > Or for simplicity we could also be testing against skb_headlen()
> > > since we don't expect any legit non-linear frames here? Dunno.
> >
> > I'll be glad to change this either way, your call. Given that this is
> > an obsolete protocol that seems to only be a target for drive-by fuzzers
> > to attack, whatever the simplest thing to do to quiet them up I'll be
> > glad to implement.
> >
> > Or can we just delete this stuff entirely? :)
>
> Yes.
>
> My thinking is to delete hamradio, nfc, atm, caif.. [more to come]
> Create GH repos which provide them as OOT modules.
> Hopefully we can convince any existing users to switch to that.
>
> The only thing stopping me is the concern that this is just the softest
> target and the LLMs will find something else to focus on which we can't
> delete. I suspect any PCIe driver can be flooded with "aren't you
> trusting the HW to provide valid responses here?" bullshit.
>
> But hey, let's try. I'll post a patch nuking all of hamradio later
> today.
Well, either we "expunge" this code to OOT repos, or we mark it
as broken and tell everyone that we don't take security fixes
for anything that depends on BROKEN. I'd personally rather expunge.
cc: workflows, we can't be the only ones still nursing Linux 2.2 code
^ permalink raw reply
* Re: maintainer profiles
From: Mauro Carvalho Chehab @ 2026-04-10 8:12 UTC (permalink / raw)
To: Randy Dunlap
Cc: Linux Documentation, Linux Kernel Mailing List, Jonathan Corbet,
Linux Kernel Workflows
In-Reply-To: <b7775383-da94-4098-8af9-2f672c4f1a71@infradead.org>
On Thu, 9 Apr 2026 17:18:39 -0700
Randy Dunlap <rdunlap@infradead.org> wrote:
> 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?
Heh, from the 5 entries at maintainer-handbooks.rst:
maintainer-netdev
maintainer-soc
maintainer-soc-clean-dts
maintainer-tip
maintainer-kvm-x86
we have 3 of them already there at maintainer-entry-profile.rst:
$ grep process/ Documentation/maintainer/maintainer-entry-profile.rst
../process/maintainer-soc
../process/maintainer-soc-clean-dts
../process/maintainer-netdev
It sounds to me that moving maintainer-tip and maintainer-kvm-x86
to maintainer-entry-profile.rst would be enough to drop
maintainer-handbooks.rst, keeping them consolidated on a single
place.
Thanks,
Mauro
^ permalink raw reply
* 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
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