* 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-next v2] iavf: fix kernel-doc comment style in iavf_ethtool.c
From: patchwork-bot+netdevbpf @ 2026-04-10 23:10 UTC (permalink / raw)
To: Loktionov, Aleksandr
Cc: intel-wired-lan, anthony.l.nguyen, netdev, leszek.pepiak
In-Reply-To: <20260409093020.3808687-1-aleksandr.loktionov@intel.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Thu, 9 Apr 2026 11:30:20 +0200 you wrote:
> iavf_ethtool.c contains 31 kernel-doc comment blocks using the legacy
> `**/` terminator instead of the correct single `*/`. Two function
> headers also use a colon separator (`iavf_get_channels:`,
> `iavf_set_channels:`) instead of the ` - ` dash required by kernel-doc.
>
> Additionally several comments embed their return-value descriptions in
> the body paragraph, producing `scripts/kernel-doc -Wreturn` warnings.
> Void functions that incorrectly say "Returns ..." are also rephrased.
>
> [...]
Here is the summary with links:
- [net-next,v2] iavf: fix kernel-doc comment style in iavf_ethtool.c
https://git.kernel.org/netdev/net-next/c/3f3a2aefbc66
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next 0/3] net: dsa: mxl862xx: VLAN support and minor improvements
From: patchwork-bot+netdevbpf @ 2026-04-10 23:10 UTC (permalink / raw)
To: Daniel Golle
Cc: andrew, olteanv, davem, edumazet, kuba, pabeni, linux, netdev,
linux-kernel, frankwu, chad, cezary.wilmanski, lxu, yweng, jverdu,
ajayaraman, john
In-Reply-To: <cover.1775581804.git.daniel@makrotopia.org>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 7 Apr 2026 18:30:14 +0100 you wrote:
> This series adds VLAN offloading to the mxl862xx DSA driver along
> with two minor improvements to port setup and bridge configuration.
> VLAN support uses a hybrid architecture combining the Extended VLAN
> engine for PVID insertion and tag stripping with the VLAN Filter
> engine for per-port VID membership, both drawing from shared
> 1024-entry hardware pools partitioned across user ports at probe time.
>
> [...]
Here is the summary with links:
- [net-next,1/3] net: dsa: mxl862xx: reject DSA_PORT_TYPE_DSA
https://git.kernel.org/netdev/net-next/c/3a4056ec7ec8
- [net-next,2/3] net: dsa: mxl862xx: don't skip early bridge port configuration
https://git.kernel.org/netdev/net-next/c/71934b9e6f36
- [net-next,3/3] net: dsa: mxl862xx: implement VLAN functionality
https://git.kernel.org/netdev/net-next/c/d587f9b6dcc9
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next v4 0/3] net: bridge: add stp_mode attribute for STP mode selection
From: patchwork-bot+netdevbpf @ 2026-04-10 23:10 UTC (permalink / raw)
To: Andy Roulin
Cc: netdev, bridge, razor, idosch, andrew+netdev, davem, edumazet,
kuba, pabeni, horms, corbet, shuah, petrm, donald.hunter,
jonas.gorski, linux-doc, linux-kselftest, linux-kernel
In-Reply-To: <20260405205224.3163000-1-aroulin@nvidia.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Sun, 5 Apr 2026 13:52:21 -0700 you wrote:
> The bridge-stp usermode helper is currently restricted to the initial
> network namespace, preventing userspace STP daemons like mstpd from
> operating on bridges in other namespaces. Since commit ff62198553e4
> ("bridge: Only call /sbin/bridge-stp for the initial network
> namespace"), bridges in non-init namespaces silently fall back to
> kernel STP with no way to request userspace STP.
>
> [...]
Here is the summary with links:
- [net-next,v4,1/3] net: bridge: add stp_mode attribute for STP mode selection
https://git.kernel.org/netdev/net-next/c/54fc83a17285
- [net-next,v4,2/3] docs: net: bridge: document stp_mode attribute
https://git.kernel.org/netdev/net-next/c/c4f2aab121cd
- [net-next,v4,3/3] selftests: net: add bridge STP mode selection test
https://git.kernel.org/netdev/net-next/c/20ae6d76e381
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix FE_PSE_BUF_SET configuration if PPE2 is available
From: patchwork-bot+netdevbpf @ 2026-04-10 23:10 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, horms,
linux-arm-kernel, linux-mediatek, netdev, xuegang.lu
In-Reply-To: <20260408-airoha-reg_fe_pse_buf_set-v1-1-0c4fa8f4d1d9@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 08 Apr 2026 12:20:09 +0200 you wrote:
> airoha_fe_set routine is used to set specified bits to 1 in the selected
> register. In the FE_PSE_BUF_SET case this can due to a overestimation of
> the required buffers for I/O queues since we can miss to set some bits
> of PSE_ALLRSV_MASK subfield to 0. Fix the issue relying on airoha_fe_rmw
> routine instead.
>
> Fixes: 8e38e08f2c560 ("net: airoha: fix PSE memory configuration in airoha_fe_pse_ports_init()")
> Tested-by: Xuegang Lu <xuegang.lu@airoha.com>
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
>
> [...]
Here is the summary with links:
- [net] net: airoha: Fix FE_PSE_BUF_SET configuration if PPE2 is available
https://git.kernel.org/netdev/net/c/02f729643959
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 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
* [PATCH net-next] net: shaper: Reject zero weight in shaper config
From: Mohsin Bashir @ 2026-04-10 22:51 UTC (permalink / raw)
To: netdev
Cc: ast, chuck.lever, davem, donald.hunter, edumazet, horms, kuba,
linux-kernel, matttbe, pabeni, mohsin.bashr
A zero weight is meaningless for DWRR scheduling and can cause
starvation of the affected node. Add a min-value constraint to
the weight attribute in the net_shaper netlink spec so that zero
is rejected at the netlink policy level.
Found while prototyping a new driver, existing drivers are not
affected.
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Mohsin Bashir <hmohsin@meta.com>
---
Documentation/netlink/specs/net_shaper.yaml | 2 ++
net/shaper/shaper_nl_gen.c | 6 +++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/Documentation/netlink/specs/net_shaper.yaml b/Documentation/netlink/specs/net_shaper.yaml
index 3f2ad772b64b..7216568fcfc5 100644
--- a/Documentation/netlink/specs/net_shaper.yaml
+++ b/Documentation/netlink/specs/net_shaper.yaml
@@ -106,6 +106,8 @@ attribute-sets:
-
name: weight
type: u32
+ checks:
+ min: 1
doc: |
Relative weight for round robin scheduling of the
given shaper.
diff --git a/net/shaper/shaper_nl_gen.c b/net/shaper/shaper_nl_gen.c
index 9b29be3ef19a..0cad1a355350 100644
--- a/net/shaper/shaper_nl_gen.c
+++ b/net/shaper/shaper_nl_gen.c
@@ -20,7 +20,7 @@ const struct nla_policy net_shaper_handle_nl_policy[NET_SHAPER_A_HANDLE_ID + 1]
const struct nla_policy net_shaper_leaf_info_nl_policy[NET_SHAPER_A_WEIGHT + 1] = {
[NET_SHAPER_A_HANDLE] = NLA_POLICY_NESTED(net_shaper_handle_nl_policy),
[NET_SHAPER_A_PRIORITY] = { .type = NLA_U32, },
- [NET_SHAPER_A_WEIGHT] = { .type = NLA_U32, },
+ [NET_SHAPER_A_WEIGHT] = NLA_POLICY_MIN(NLA_U32, 1),
};
/* NET_SHAPER_CMD_GET - do */
@@ -43,7 +43,7 @@ static const struct nla_policy net_shaper_set_nl_policy[NET_SHAPER_A_IFINDEX + 1
[NET_SHAPER_A_BW_MAX] = { .type = NLA_UINT, },
[NET_SHAPER_A_BURST] = { .type = NLA_UINT, },
[NET_SHAPER_A_PRIORITY] = { .type = NLA_U32, },
- [NET_SHAPER_A_WEIGHT] = { .type = NLA_U32, },
+ [NET_SHAPER_A_WEIGHT] = NLA_POLICY_MIN(NLA_U32, 1),
};
/* NET_SHAPER_CMD_DELETE - do */
@@ -62,7 +62,7 @@ static const struct nla_policy net_shaper_group_nl_policy[NET_SHAPER_A_LEAVES +
[NET_SHAPER_A_BW_MAX] = { .type = NLA_UINT, },
[NET_SHAPER_A_BURST] = { .type = NLA_UINT, },
[NET_SHAPER_A_PRIORITY] = { .type = NLA_U32, },
- [NET_SHAPER_A_WEIGHT] = { .type = NLA_U32, },
+ [NET_SHAPER_A_WEIGHT] = NLA_POLICY_MIN(NLA_U32, 1),
[NET_SHAPER_A_LEAVES] = NLA_POLICY_NESTED(net_shaper_leaf_info_nl_policy),
};
--
2.52.0
^ permalink raw reply related
* [PATCH iproute 2/2] json_writer: fix builtin test code
From: Stephen Hemminger @ 2026-04-10 22:47 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
In-Reply-To: <20260410224745.93416-1-stephen@networkplumber.org>
The code under #ifdef was not generating valid JSON
and it is missing test for control characters.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/json_writer.c | 11 +++++++++--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/lib/json_writer.c b/lib/json_writer.c
index 7202621e..d4a1c72b 100644
--- a/lib/json_writer.c
+++ b/lib/json_writer.c
@@ -369,7 +369,7 @@ int main(int argc, char **argv)
jsonw_null_field(wr, "my_null");
jsonw_name(wr, "special chars");
- jsonw_start_array(wr);
+ jsonw_start_object(wr);
jsonw_string_field(wr, "slash", "/");
jsonw_string_field(wr, "newline", "\n");
jsonw_string_field(wr, "tab", "\t");
@@ -377,7 +377,14 @@ int main(int argc, char **argv)
jsonw_string_field(wr, "quote", "\"");
jsonw_string_field(wr, "tick", "\'");
jsonw_string_field(wr, "backslash", "\\");
- jsonw_end_array(wr);
+ jsonw_end_object(wr);
+
+ jsonw_name(wr, "control chars");
+ jsonw_start_object(wr);
+ jsonw_string_field(wr, "bell", "\a");
+ jsonw_string_field(wr, "esc", "\033");
+ jsonw_string_field(wr, "del", "\177");
+ jsonw_end_object(wr);
jsonw_end_object(wr);
--
2.53.0
^ permalink raw reply related
* [PATCH iproute 1/2] json_writer: support control character escaping
From: Stephen Hemminger @ 2026-04-10 22:47 UTC (permalink / raw)
To: netdev; +Cc: Stephen Hemminger
Iproute2 never handled control characters in strings correctly.
There are some cases like where string is under user control
like paths in ss command. Make iproute2 json output conform
to RFC 8259.
Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
---
lib/json_writer.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/json_writer.c b/lib/json_writer.c
index 2f3936c2..7202621e 100644
--- a/lib/json_writer.c
+++ b/lib/json_writer.c
@@ -53,7 +53,7 @@ static void jsonw_eor(json_writer_t *self)
/* Output JSON encoded string */
-/* Handles C escapes, does not do Unicode */
+/* Handles C escapes and control characters per RFC 8259 */
static void jsonw_puts(json_writer_t *self, const char *str)
{
putc('"', self->out);
@@ -81,7 +81,10 @@ static void jsonw_puts(json_writer_t *self, const char *str)
fputs("\\\"", self->out);
break;
default:
- putc(*str, self->out);
+ if ((unsigned char)*str < 0x20 || *str == 0x7f)
+ fprintf(self->out, "\\u%04x", *str);
+ else
+ putc(*str, self->out);
}
putc('"', self->out);
}
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net-next 0/2] Add selftests for ntuple (NFC) rules
From: patchwork-bot+netdevbpf @ 2026-04-10 22:40 UTC (permalink / raw)
To: Dimitri Daskalakis
Cc: davem, andrew+netdev, edumazet, kuba, pabeni, shuah, willemb,
petrm, dw, carges, cjubran, daskald, netdev, linux-kselftest
In-Reply-To: <20260407164954.2977820-1-dimitri.daskalakis1@gmail.com>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 7 Apr 2026 09:49:52 -0700 you wrote:
> From: Dimitri Daskalakis <daskald@meta.com>
>
> Thoroughly testing a device's NFC implementation can be tedious. The more
> features a device supports, the more combinations to validate.
>
> This series aims to ease that burden, validating the most common NFC rule
> combinations.
>
> [...]
Here is the summary with links:
- [net-next,1/2] selftests: drv-net: Add ntuple (NFC) flow steering test
https://git.kernel.org/netdev/net-next/c/18589df9344c
- [net-next,2/2] selftests: drv-net: ntuple: Add dst-ip, src-port, dst-port fields
https://git.kernel.org/netdev/net-next/c/a66374a3eb02
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 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 iwl-net 3/4] ice: fix ready bitmap check for non-E822 devices
From: Jacob Keller @ 2026-04-10 22:32 UTC (permalink / raw)
To: Anthony Nguyen, Intel Wired LAN, netdev, Aleksandr Loktionov,
Petr Oros
Cc: Grzegorz Nitka, Timothy Miskell, Aleksandr Loktionov
In-Reply-To: <20260408-jk-even-more-e825c-fixes-v1-3-b959da91a81f@intel.com>
On 4/8/2026 11:46 AM, Jacob Keller wrote:
> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp.c b/drivers/net/ethernet/intel/ice/ice_ptp.c
> index ada42bcc4d0b..34906f972d17 100644
> --- a/drivers/net/ethernet/intel/ice/ice_ptp.c
> +++ b/drivers/net/ethernet/intel/ice/ice_ptp.c
> @@ -2718,7 +2718,7 @@ static bool ice_any_port_has_timestamps(struct ice_pf *pf)
> bool ice_ptp_tx_tstamps_pending(struct ice_pf *pf)
> {
> struct ice_hw *hw = &pf->hw;
> - unsigned int i;
> + int ret;
>
> /* Check software indicator */
> switch (pf->ptp.tx_interrupt_mode) {
> @@ -2739,16 +2739,15 @@ bool ice_ptp_tx_tstamps_pending(struct ice_pf *pf)
> }
>
> /* Check hardware indicator */
> - for (i = 0; i < ICE_GET_QUAD_NUM(hw->ptp.num_lports); i++) {
> - u64 tstamp_ready = 0;
> - int err;
> -
> - err = ice_get_phy_tx_tstamp_ready(&pf->hw, i, &tstamp_ready);
> - if (err || tstamp_ready)
> - return true;
> + ret = ice_check_phy_tx_tstamp_ready(hw);
> + if (ret < 0) {
> + dev_dbg(ice_pf_to_dev(pf), "Unable to read PHY Tx timestamp ready bitmap, err %d\n",
> + ret);
> + /* Stop triggering IRQs if we're unable to read PHY */
> + return false;
> }
>
> - return false;
> + return ret;
I got some comments off-list from Aleks about this "conversion" from
integer to boolean here. The return from ice_check_phy_tx_tstamp_ready()
is 0 when there are no timsetamps and 1 when there is at least one
timestamp available. The negative values are excluded in the check just
above this.
I guess I can re-write this to be an if/elif/else chain instead, but I
wonder what others on the list think here.
I understand it is slightly confusing to have a return which is 3-way
(error, 0 or 1), but other solutions seemed inellegant. Using a bool for
the check means we lose the nuance of the error code (and the distinct
dev_dbg message). It also doesn't let the caller decide whether its more
imporant to continue on error or stop on error (which might be dependant
on each call flow).
Just doing "ret ? true : false" seems stupid since that is literally
what this will do given that we already excluded negative values in the
check above before returning.
> +/**
> + * ice_check_phy_tx_tstamp_ready_e810 - Check Tx memory status register
> + * @hw: pointer to the HW struct
> + *
> + * The E810 devices do not have a Tx memory status register. Note this is
> + * intentionally different behavior from ice_get_phy_tx_tstamp_ready_e810
> + * which always says that all bits are ready. This function is called in cases
> + * where code will trigger interrupts if timestamps are waiting, and should
> + * not be called for E810 hardware.
> + *
> + * Return: 0.
> + */
> +static int ice_check_phy_tx_tstamp_ready_e810(struct ice_hw *hw)
> +{
> + return 0;
> +}
> +
I got comments off list about this "unused parameter" and empty
function. The E810 hardware doesn't have a ready bitmap in its
registers. Thus, this function doesn't really do anything. I'm
considering if it makes more sense to move this comment into the
hardware wrapper layer and drop this function (and thus its unused
parameter).
> +/**
> + * ice_check_phy_tx_tstamp_ready - Check PHY Tx timestamp memory status
> + * @hw: pointer to the HW struct
> + *
> + * Check the PHY for Tx timestamp memory status on all ports. If you need to
> + * see individual timestamp status for each index, use
> + * ice_get_phy_tx_tstamp_ready() instead.
> + *
> + * Return: 1 if any port has timestamps available, 0 if there are no timestamps
> + * available, and a negative error code on failure.
> + */
This type of return is somewhat confusing and rare. Typically functions
returning int either return 0 for success or a non-zero error code. In
this case there are two "success" states. C doesn't have anything like
the Error types from newer languages.
The closest example I have is functions that read from a socket or
buffer or file, which return negative error codes or the number of bytes
read/written.
I could change this API to return the total number of timestamps
available.. but every caller just cares about whether there is at least
one timestamp, so I opted to shrink it to 0/1 in order to allow eliding
unnecessary checks for devices with multiple ports.
Thoughts?
Thanks,
Jak
^ permalink raw reply
* Re: [PATCH net-next v1] net: add missing syncookie statistics for BPF custom syncookies
From: Kuniyuki Iwashima @ 2026-04-10 22:31 UTC (permalink / raw)
To: Jiayuan Chen
Cc: netdev, Eric Dumazet, Neal Cardwell, David S. Miller,
Jakub Kicinski, Paolo Abeni, Simon Horman, David Ahern,
linux-kernel, bpf
In-Reply-To: <20260409124129.361777-1-jiayuan.chen@linux.dev>
On Thu, Apr 9, 2026 at 5:41 AM Jiayuan Chen <jiayuan.chen@linux.dev> wrote:
>
> 1. Replace IS_ENABLED(CONFIG_BPF) with CONFIG_BPF_SYSCALL for
> cookie_bpf_ok() and cookie_bpf_check(). CONFIG_BPF is selected by
> CONFIG_NET unconditionally, so IS_ENABLED(CONFIG_BPF) is always
> true and provides no real guard. CONFIG_BPF_SYSCALL is the correct
> config for BPF program functionality.
>
> 2. Remove the CONFIG_BPF_SYSCALL guard around struct bpf_tcp_req_attrs.
> This struct is referenced by bpf_sk_assign_tcp_reqsk() in
> net/core/filter.c which is compiled unconditionally, so wrapping
> the definition in a config guard could cause build failures when
> CONFIG_BPF_SYSCALL=n.
>
> 3. Fix mismatched declaration of cookie_bpf_check() between the
> CONFIG_BPF_SYSCALL and stub paths: the real definition takes
> 'struct net *net' but the declaration in the header did not.
> Add the net parameter to the declaration and all call sites.
>
> 4. Add missing LINUX_MIB_SYNCOOKIESRECV and LINUX_MIB_SYNCOOKIESFAILED
> statistics in cookie_bpf_check(), so that BPF custom syncookie
> validation is accounted for in SNMP counters just like the
> non-BPF path.
>
> Compile-tested with CONFIG_BPF_SYSCALL=y and CONFIG_BPF_SYSCALL
> not set.
Can you add SNMP test in tcp_custom_syncookie.c by checking
the delta before connect_to_fd() and after accept() ?
>
> Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
> ---
> No functional bug here — CONFIG_BPF is always enabled under
> CONFIG_NET, so the existing code compiles and works correctly.
> This is a cleanup and improvement, no backport needed.
> ---
> include/net/tcp.h | 7 +++----
> net/ipv4/syncookies.c | 10 +++++++---
> net/ipv6/syncookies.c | 2 +-
> 3 files changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index 6156d1d068e1..570a8836c2ba 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -598,7 +598,6 @@ struct request_sock *cookie_tcp_reqsk_alloc(const struct request_sock_ops *ops,
> struct tcp_options_received *tcp_opt,
> int mss, u32 tsoff);
>
> -#if IS_ENABLED(CONFIG_BPF)
> struct bpf_tcp_req_attrs {
> u32 rcv_tsval;
> u32 rcv_tsecr;
> @@ -612,7 +611,6 @@ struct bpf_tcp_req_attrs {
> u8 usec_ts_ok;
> u8 reserved[3];
> };
> -#endif
>
> #ifdef CONFIG_SYN_COOKIES
>
> @@ -715,13 +713,14 @@ static inline bool cookie_ecn_ok(const struct net *net, const struct dst_entry *
> dst_feature(dst, RTAX_FEATURE_ECN);
> }
>
> -#if IS_ENABLED(CONFIG_BPF)
> +#ifdef CONFIG_BPF_SYSCALL
> static inline bool cookie_bpf_ok(struct sk_buff *skb)
> {
> return skb->sk;
> }
>
> -struct request_sock *cookie_bpf_check(struct sock *sk, struct sk_buff *skb);
> +struct request_sock *cookie_bpf_check(struct net *net, struct sock *sk,
> + struct sk_buff *skb);
> #else
> static inline bool cookie_bpf_ok(struct sk_buff *skb)
> {
> diff --git a/net/ipv4/syncookies.c b/net/ipv4/syncookies.c
> index f1474598d2c8..d685631438cb 100644
> --- a/net/ipv4/syncookies.c
> +++ b/net/ipv4/syncookies.c
> @@ -295,8 +295,9 @@ static int cookie_tcp_reqsk_init(struct sock *sk, struct sk_buff *skb,
> return 0;
> }
>
> -#if IS_ENABLED(CONFIG_BPF)
> -struct request_sock *cookie_bpf_check(struct sock *sk, struct sk_buff *skb)
> +#ifdef CONFIG_BPF_SYSCALL
> +struct request_sock *cookie_bpf_check(struct net *net, struct sock *sk,
> + struct sk_buff *skb)
> {
> struct request_sock *req = inet_reqsk(skb->sk);
>
> @@ -306,6 +307,9 @@ struct request_sock *cookie_bpf_check(struct sock *sk, struct sk_buff *skb)
> if (cookie_tcp_reqsk_init(sk, skb, req)) {
> reqsk_free(req);
> req = NULL;
> + __NET_INC_STATS(net, LINUX_MIB_SYNCOOKIESFAILED);
> + } else {
> + __NET_INC_STATS(net, LINUX_MIB_SYNCOOKIESRECV);
> }
>
> return req;
> @@ -419,7 +423,7 @@ struct sock *cookie_v4_check(struct sock *sk, struct sk_buff *skb)
> goto out;
>
> if (cookie_bpf_ok(skb)) {
> - req = cookie_bpf_check(sk, skb);
> + req = cookie_bpf_check(net, sk, skb);
> } else {
> req = cookie_tcp_check(net, sk, skb);
> if (IS_ERR(req))
> diff --git a/net/ipv6/syncookies.c b/net/ipv6/syncookies.c
> index 4f6f0d751d6c..111d7a41d957 100644
> --- a/net/ipv6/syncookies.c
> +++ b/net/ipv6/syncookies.c
> @@ -190,7 +190,7 @@ struct sock *cookie_v6_check(struct sock *sk, struct sk_buff *skb)
> goto out;
>
> if (cookie_bpf_ok(skb)) {
> - req = cookie_bpf_check(sk, skb);
> + req = cookie_bpf_check(net, sk, skb);
> } else {
> req = cookie_tcp_check(net, sk, skb);
> if (IS_ERR(req))
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v2] net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf
From: patchwork-bot+netdevbpf @ 2026-04-10 22:30 UTC (permalink / raw)
To: Mashiro Chen
Cc: netdev, horms, davem, edumazet, kuba, pabeni, linux-hams, stable,
syzbot+ecdb8c9878a81eb21e54
In-Reply-To: <20260407173101.107352-1-mashiro.chen@mailbox.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 8 Apr 2026 01:31:01 +0800 you wrote:
> sixpack_receive_buf() does not properly skip bytes with TTY error flags.
> The while loop iterates through the flags buffer but never advances the
> data pointer (cp), and passes the original count (including error bytes)
> to sixpack_decode(). This causes sixpack_decode() to process bytes that
> should have been skipped due to TTY errors. The TTY layer does not
> guarantee that cp[i] holds a meaningful value when fp[i] is set, so
> passing those positions to sixpack_decode() results in KMSAN reporting
> an uninit-value read.
>
> [...]
Here is the summary with links:
- [v2] net: hamradio: 6pack: fix uninit-value in sixpack_receive_buf
https://git.kernel.org/netdev/net/c/bf9a38803b26
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH 5/5] selftests: net: add rss_multiqueue test variant to iou-zcrx
From: David Wei @ 2026-04-10 22:26 UTC (permalink / raw)
To: Juanlu Herrero, netdev
In-Reply-To: <20260408163816.2760-6-juanlu@fastmail.com>
On 2026-04-08 09:38, Juanlu Herrero wrote:
> Add multi-port support to the iou-zcrx test binary and a new
> rss_multiqueue Python test variant that exercises multi-queue zero-copy
> receive with per-port flow rule steering.
>
> In multi-port mode, the server creates N listening sockets on
> consecutive ports (cfg_port, cfg_port+1, ...) and uses epoll to accept
> one connection per socket. Each client thread connects to its
> corresponding port. Per-port ntuple flow rules steer traffic to
> different NIC hardware queues, each with its own zcrx instance.
>
> For single-thread mode (the default), behavior is unchanged: one socket
> on cfg_port, one thread, one queue.
>
> Signed-off-by: Juanlu Herrero <juanlu@fastmail.com>
> ---
> .../selftests/drivers/net/hw/iou-zcrx.c | 81 ++++++++++++++-----
> .../selftests/drivers/net/hw/iou-zcrx.py | 45 ++++++++++-
> 2 files changed, 104 insertions(+), 22 deletions(-)
>
> diff --git a/tools/testing/selftests/drivers/net/hw/iou-zcrx.c b/tools/testing/selftests/drivers/net/hw/iou-zcrx.c
> index 646682167bb0..1f33d7127185 100644
> --- a/tools/testing/selftests/drivers/net/hw/iou-zcrx.c
> +++ b/tools/testing/selftests/drivers/net/hw/iou-zcrx.c
Please make all changes in iou-zcrx.c in a single patch. Then patch 5
only changes the Python selftest.
[...]
> @@ -397,12 +410,36 @@ static void run_server(void)
> if (cfg_dry_run)
> goto join;
>
> + epfd = epoll_create1(0);
> + if (epfd < 0)
> + error(1, 0, "epoll_create1()");
> +
> for (i = 0; i < cfg_num_threads; i++) {
> - ctxs[i].connfd = accept(fd, NULL, NULL);
> - if (ctxs[i].connfd < 0)
> - error(1, 0, "accept()");
> + ev.events = EPOLLIN;
> + ev.data.u32 = i;
> + if (epoll_ctl(epfd, EPOLL_CTL_ADD, fds[i], &ev) < 0)
> + error(1, 0, "epoll_ctl()");
> }
>
> + accepted = 0;
> + while (accepted < cfg_num_threads) {
You're using epoll here but it is still accepting a fixed nr of
connections. The server should be able to accept an arbitrary nr of
connections, dispatching them to the server worker threads.
Also with multiple queues, connections must be dispatched according to
their NAPI IDs to the correct server workers.
> + nfds = epoll_wait(epfd, events, 64, 5000);
> + if (nfds < 0)
> + error(1, 0, "epoll_wait()");
> + if (nfds == 0)
> + error(1, 0, "epoll_wait() timeout");
> +
> + for (i = 0; i < nfds; i++) {
> + int idx = events[i].data.u32;
> +
> + ctxs[idx].connfd = accept(fds[idx], NULL, NULL);
> + if (ctxs[idx].connfd < 0)
> + error(1, 0, "accept()");
> + accepted++;
> + }
> + }
> +
> + close(epfd);
> pthread_barrier_wait(&barrier);
>
> join:
^ 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 iwl-next] i40e: PTP: set supported flags in ptp_clock_info
From: Jacob Keller @ 2026-04-10 22:09 UTC (permalink / raw)
To: Korba, Przemyslaw, Simon Horman
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
Nguyen, Anthony L, Kitszel, Przemyslaw
In-Reply-To: <PH0PR11MB4904AB3C1045FA1A2F99A03194592@PH0PR11MB4904.namprd11.prod.outlook.com>
On 4/10/2026 6:20 AM, Korba, Przemyslaw wrote:
>> -----Original Message-----
>> From: Keller, Jacob E <jacob.e.keller@intel.com>
>> Sent: Thursday, March 26, 2026 1:15 AM
>> To: Korba, Przemyslaw <przemyslaw.korba@intel.com>; Simon Horman <horms@kernel.org>
>> Cc: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
>> <przemyslaw.kitszel@intel.com>
>> Subject: Re: [PATCH iwl-next] i40e: PTP: set supported flags in ptp_clock_info
>>
>> On 3/13/2026 6:47 AM, Korba, Przemyslaw wrote:
>>>> -----Original Message-----
>>>> From: Simon Horman <horms@kernel.org>
>>>> Sent: Friday, March 13, 2026 2:35 PM
>>>> To: Korba, Przemyslaw <przemyslaw.korba@intel.com>
>>>> Cc: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
>>>> <przemyslaw.kitszel@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>
>>>> Subject: Re: [PATCH iwl-next] i40e: PTP: set supported flags in ptp_clock_info
>> Yes, Simon is correct, but we do have to be certain that the driver
>> actually implements the facts correctly, i.e. that it will actually
>> honor the RISING or FALLING edge, before you actually add the flags to
>> the supported flags list.
>>
>> I don't see any mention of PTP_RISING_EDGE nor PTP_FALLING_EDGE in the
>> driver. Thus, I can't confirm which edge is actually timestamped.
>>
>> Thus I would NACK this patch until you can confirm whether the hardware
>> either a) timestamps one edge, in which case you should set only that
>> flag as allowed, b) timestamps both edges, in which case you should set
>> all flags and then explicitly reject the case where only one flag is
>> set, or c) can be configured based on which flag is set, in which case
>> you should set all the flags and then check the flags when programming
>> to enable the appropriate edge.
>>
>> This patch does none of these, and is therefor incorrect. Applying it
>> will "allow" the userspace to work but they will not get the strict
>> behavior of timestamping the desired edge, which completely negates the
>> point of the strict mode!
>>
>> As an example, look at the ice driver:
>>
>> #define GLTSYN_AUX_IN_0_EVNTLVL_RISING_EDGE BIT(0)
>> #define GLTSYN_AUX_IN_0_EVNTLVL_FALLING_EDGE BIT(1)
>>
>> /* set event level to requested edge */
>> if (rq->flags & PTP_FALLING_EDGE)
>> aux_reg |= GLTSYN_AUX_IN_0_EVNTLVL_FALLING_EDGE;
>> if (rq->flags & PTP_RISING_EDGE)
>> aux_reg |= GLTSYN_AUX_IN_0_EVNTLVL_RISING_EDGE;
>>
>>
>> It sets the appropriate register values to ensure the correct edges are
>> timestamped as requested.
>>
>> Thanks,
>> Jake
>
> Hi, thank you for your review, and sorry for late response.
> The original point of this patch was to fix the issue, where ts2phc fails due to not seeing supported flags
> (now when I think about it iwl-net would be a better place for this patch)
> I've read in our documentation FVL supports both rising, falling and both edges,
> but in i40e_ptp_set_timestamp_mode we are hardcoding EVNTLVL register to Rising edge only.
> Implementing other edges would require DCR, and I couldn't find anything like that.
> I think for now setting the rising edge as a supported flag would be the way to go. Do you agree?
Agreed. I would propose the following path to resolving this:
a) as a net fix, set the flag to match what the driver actually enables.
If this is Rising edge only, then set the rising edge and strict flag.
Strictly, this is a bug introduced by commit 1050713026a0 ("i40e: add
support for PTP external synchronization clock"), because this commit
added support for EXTTS output without checking the flags, but.. the
original issue was being too accepting, while the new issue is being
caused by silently excluding the flags because the flags aren't listed
as supported. Thus, use Fixes: 7c571ac57d9d ("net: ptp: introduce
.supported_extts_flags to ptp_clock_info")
Since you confirmed that the driver explicitly sets rising edge support,
you should set STRICT_FLAGS and RISING_EDGE in the
.supported_extts_flags field.
b) as a net-next improvement, add support for both flags and
conditionally set the register to program the desired edge. This might
take longer if we need to go through internal approval for a new
feature, but in my opinion this is small and obviously correct and
something we should support within the PTP ecosystem. Since the window
will be closing soon this part should wait until after it re-opens in 2
weeks.
^ permalink raw reply
* [PATCH net-next] net: airoha: Wait for TX to complete in airoha_dev_stop()
From: Lorenzo Bianconi @ 2026-04-10 22:05 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Lorenzo Bianconi
Wait for TX to complete in airoha_dev_stop routine before stopping the
TX DMA and run airoha_qdma_cleanup_tx_queue routine. Moreover,
start/stop TX/RX NAPIs in ndo_open()/ndo_stop() callbacks in order to be
sure the TX NAPIs have completed before stopping the TX DMA engine in
airoha_dev_stop routine.
Please note this patch on the commit 'b1c803d5c816 ("net: airoha: Rework
the code flow in airoha_remove() and in airoha_probe() error path")'
that is available only in net-next tree at the moment.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 44 +++++++++++++++++---------------
1 file changed, 24 insertions(+), 20 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 8e4b043af4bc..9e40c8f375c1 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1662,10 +1662,12 @@ static int airoha_dev_open(struct net_device *dev)
FIELD_PREP(GDM_SHORT_LEN_MASK, 60) |
FIELD_PREP(GDM_LONG_LEN_MASK, len));
- airoha_qdma_set(qdma, REG_QDMA_GLOBAL_CFG,
- GLOBAL_CFG_TX_DMA_EN_MASK |
- GLOBAL_CFG_RX_DMA_EN_MASK);
- atomic_inc(&qdma->users);
+ if (!atomic_fetch_inc(&qdma->users)) {
+ airoha_qdma_set(qdma, REG_QDMA_GLOBAL_CFG,
+ GLOBAL_CFG_TX_DMA_EN_MASK |
+ GLOBAL_CFG_RX_DMA_EN_MASK);
+ airoha_qdma_start_napi(qdma);
+ }
if (port->id == AIROHA_GDM2_IDX &&
airoha_ppe_is_enabled(qdma->eth, 1)) {
@@ -1684,18 +1686,26 @@ static int airoha_dev_stop(struct net_device *dev)
struct airoha_qdma *qdma = port->qdma;
int i, err;
- netif_tx_disable(dev);
err = airoha_set_vip_for_gdm_port(port, false);
if (err)
return err;
- for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++)
- netdev_tx_reset_subqueue(dev, i);
-
airoha_set_gdm_port_fwd_cfg(qdma->eth, REG_GDM_FWD_CFG(port->id),
FE_PSE_PORT_DROP);
+ netif_tx_disable(dev);
if (atomic_dec_and_test(&qdma->users)) {
+ u32 val;
+
+ /* Wait for TX to complete */
+ err = read_poll_timeout(airoha_qdma_rr, val,
+ !(val & GLOBAL_CFG_TX_DMA_BUSY_MASK),
+ USEC_PER_MSEC, 100 * USEC_PER_MSEC,
+ false, qdma, REG_QDMA_GLOBAL_CFG);
+ if (err)
+ return err;
+
+ airoha_qdma_stop_napi(qdma);
airoha_qdma_clear(qdma, REG_QDMA_GLOBAL_CFG,
GLOBAL_CFG_TX_DMA_EN_MASK |
GLOBAL_CFG_RX_DMA_EN_MASK);
@@ -1708,6 +1718,9 @@ static int airoha_dev_stop(struct net_device *dev)
}
}
+ for (i = 0; i < ARRAY_SIZE(qdma->q_tx); i++)
+ netdev_tx_reset_subqueue(dev, i);
+
return 0;
}
@@ -3048,9 +3061,6 @@ static int airoha_probe(struct platform_device *pdev)
if (err)
goto error_netdev_free;
- for (i = 0; i < ARRAY_SIZE(eth->qdma); i++)
- airoha_qdma_start_napi(ð->qdma[i]);
-
for_each_child_of_node(pdev->dev.of_node, np) {
if (!of_device_is_compatible(np, "airoha,eth-mac"))
continue;
@@ -3061,20 +3071,17 @@ static int airoha_probe(struct platform_device *pdev)
err = airoha_alloc_gdm_port(eth, np);
if (err) {
of_node_put(np);
- goto error_napi_stop;
+ goto error_netdev_unregister;
}
}
err = airoha_register_gdm_devices(eth);
if (err)
- goto error_napi_stop;
+ goto error_netdev_unregister;
return 0;
-error_napi_stop:
- for (i = 0; i < ARRAY_SIZE(eth->qdma); i++)
- airoha_qdma_stop_napi(ð->qdma[i]);
-
+error_netdev_unregister:
for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
struct airoha_gdm_port *port = eth->ports[i];
@@ -3098,9 +3105,6 @@ static void airoha_remove(struct platform_device *pdev)
struct airoha_eth *eth = platform_get_drvdata(pdev);
int i;
- for (i = 0; i < ARRAY_SIZE(eth->qdma); i++)
- airoha_qdma_stop_napi(ð->qdma[i]);
-
for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
struct airoha_gdm_port *port = eth->ports[i];
---
base-commit: 42f9b4c6ef19e71d2c7d9bfd3c5037d4fe434ad7
change-id: 20260410-airoha-fix-ndo_stop-ebbf3c724ae0
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* 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
* [PATCH v1 net-next] selftest: net: Use port outside of the default ip_local_ports in csum.c.
From: Kuniyuki Iwashima @ 2026-04-10 21:54 UTC (permalink / raw)
To: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: Simon Horman, Willem de Bruijn, Mahesh Bandewar,
Kuniyuki Iwashima, Kuniyuki Iwashima, netdev
csum.c binds a socket on a fixed port in init_net to test
the csum offload feature between two machines.
In our testbed, the test sometimes fails with -EADDRINUSE.
bind r: Address already in use
bind dgram 6: Address already in use
The fixed ports (33000, 33001, 34000) are all within the default
ip_local_ports range (32768 ~ 60999), and other processes may
happen to be using them.
Let's use ports outside of the default ip_local_ports range to
deflake the test.
# cat /etc/services | grep -E "(13000|13001|13002)" | echo no service
no service
# rpm -qf /etc/services
setup-2.15.0-28.fc44.noarch
We could add an option to specify ports if needed.
Suggested-by: Mahesh Bandewar <maheshb@google.com>
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
---
tools/testing/selftests/net/lib/csum.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/testing/selftests/net/lib/csum.c b/tools/testing/selftests/net/lib/csum.c
index e28884ce3ab3..4e044689bc37 100644
--- a/tools/testing/selftests/net/lib/csum.c
+++ b/tools/testing/selftests/net/lib/csum.c
@@ -105,9 +105,9 @@ static char *cfg_mac_src;
static int cfg_proto = IPPROTO_UDP;
static int cfg_payload_char = 'a';
static int cfg_payload_len = 100;
-static uint16_t cfg_port_dst = 34000;
-static uint16_t cfg_port_src = 33000;
-static uint16_t cfg_port_src_encap = 33001;
+static uint16_t cfg_port_dst = 13000;
+static uint16_t cfg_port_src = 13001;
+static uint16_t cfg_port_src_encap = 13002;
static unsigned int cfg_random_seed;
static int cfg_rcvbuf = 1 << 22; /* be able to queue large cfg_num_pkt */
static bool cfg_send_pfpacket;
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
* [PATCH net] net: airoha: Add missing bits in airoha_qdma_cleanup_tx_queue()
From: Lorenzo Bianconi @ 2026-04-10 21:49 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: linux-arm-kernel, linux-mediatek, netdev, Lorenzo Bianconi
Similar to airoha_qdma_cleanup_rx_queue(), reset DMA TX descriptors in
airoha_qdma_cleanup_tx_queue routine. Moreover, reset TX_DMA_IDX to
TX_CPU_IDX to notify the NIC the QDMA TX ring is empty.
Fixes: 23020f0493270 ("net: airoha: Introduce ethernet support for EN7581 SoC")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 31 ++++++++++++++++++++++++++++---
1 file changed, 28 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 9285a68f435f..963ab7b8d166 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -1044,13 +1044,17 @@ static int airoha_qdma_init_tx(struct airoha_qdma *qdma)
static void airoha_qdma_cleanup_tx_queue(struct airoha_queue *q)
{
- struct airoha_eth *eth = q->qdma->eth;
- int i;
+ struct airoha_qdma *qdma = q->qdma;
+ struct airoha_eth *eth = qdma->eth;
+ int i, qid = q - &qdma->q_tx[0];
+ struct airoha_queue_entry *e;
+ u16 index;
spin_lock_bh(&q->lock);
for (i = 0; i < q->ndesc; i++) {
- struct airoha_queue_entry *e = &q->entry[i];
+ struct airoha_qdma_desc *desc = &q->desc[i];
+ e = &q->entry[i];
if (!e->dma_addr)
continue;
@@ -1060,8 +1064,29 @@ static void airoha_qdma_cleanup_tx_queue(struct airoha_queue *q)
e->dma_addr = 0;
e->skb = NULL;
list_add_tail(&e->list, &q->tx_list);
+
+ /* Reset DMA descriptor */
+ WRITE_ONCE(desc->ctrl, 0);
+ WRITE_ONCE(desc->addr, 0);
+ WRITE_ONCE(desc->data, 0);
+ WRITE_ONCE(desc->msg0, 0);
+ WRITE_ONCE(desc->msg1, 0);
+ WRITE_ONCE(desc->msg2, 0);
+
q->queued--;
}
+
+ e = list_first_entry(&q->tx_list, struct airoha_queue_entry,
+ list);
+ index = e - q->entry;
+ /* Set TX_DMA_IDX to TX_CPU_IDX to notify the hw the QDMA TX ring is
+ * empty.
+ */
+ airoha_qdma_rmw(qdma, REG_TX_CPU_IDX(qid), TX_RING_CPU_IDX_MASK,
+ FIELD_PREP(TX_RING_CPU_IDX_MASK, index));
+ airoha_qdma_rmw(qdma, REG_TX_DMA_IDX(qid), TX_RING_DMA_IDX_MASK,
+ FIELD_PREP(TX_RING_DMA_IDX_MASK, index));
+
spin_unlock_bh(&q->lock);
}
---
base-commit: 12ff2a4aee6c86746623d5aed24389dbf6dffded
change-id: 20260410-airoha_qdma_cleanup_tx_queue-fix-net-93375f5ee80f
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* Re: [PATCH next-next v2] net:mctp: fix setting mctp hdr ver reserved field cause data dropped
From: Jakub Kicinski @ 2026-04-10 21:43 UTC (permalink / raw)
To: wit_yuan; +Cc: netdev, Yuan Zhaoming
In-Reply-To: <20260410063334.7531-2-yuanzhaoming901030@126.com>
On Fri, 10 Apr 2026 14:33:34 +0800 wit_yuan wrote:
> From: Yuan Zhaoming <yuanzm2@lenovo.com>
>
> from spec dsp0236_1.2.1.pdf page 26, the mctp header contains the
> RSVD(4bit) and Hdr version(4 bit).
>
> mctp_pkttype_receive invoke mctp_hdr, and get mh->ver whole byte
> compare the MCTP_VER_MIN, MCTP_VER_MAX. the reserver bits may be by
> misleading used.
>
> one type hba card will set pcie vdm header Pad Len the same with RSVD
> bit, this will not work on mctp kernel solution.
We ask that:
- new patches are not posted in reply to old ones
- at least 24h passes before new version is posted
> + if (((mh->ver & MCTP_HDR_VER_MASK)) < MCTP_VER_MIN || (mh->ver & MCTP_HDR_VER_MASK) > MCTP_VER_MAX)
> goto out;
Please save the masked version to a variable and compare that extracted
variable. This line is unnecessarily long (max line length is 80 in
networking).
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net] netrom: do some basic forms of validation on incoming frames
From: Jakub Kicinski @ 2026-04-10 21:30 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
In-Reply-To: <2026041026-excuse-slashing-c4ee@gregkh>
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:
> > On Thu, 9 Apr 2026 20:03:28 +0100 Simon Horman wrote:
> > > I expect that checking skb->len isn't sufficient here
> > > and pskb_may_pull needs to be used to ensure that
> > > the data is also available in the linear section of the skb.
> >
> > 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.
^ permalink raw reply
* [PATCH v2 net-next 15/15] ip6mr: Replace RTNL with a dedicated mutex for MFC.
From: Kuniyuki Iwashima @ 2026-04-10 21:17 UTC (permalink / raw)
To: David S . Miller, David Ahern, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Simon Horman, Kuniyuki Iwashima, Kuniyuki Iwashima, netdev
In-Reply-To: <20260410211726.1668756-1-kuniyu@google.com>
ip6mr does not have rtnetlink interface for MFC unlike ipmr,
which uses dev_get_by_index_rcu() to set struct mfcctl.mfcc_parent.
ip6mr_mfc_add() and ip6mr_mfc_delete() are called under RTNL
from ip6_mroute_setsockopt() only.
There are no RTNL dependant, but ip6_mroute_setsockopt() reuses
RTNL just for mrt->mfc_hash and mrt->mfc_cache_list.
Let's replace RTNL with a new per-netns mutex.
Later, ip6mr_notifier_ops and ipmr_seq will be moved under
CONFIG_IPV6_MROUTE.
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
---
include/net/netns/ipv6.h | 1 +
net/ipv6/ip6mr.c | 21 ++++++++++++++-------
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/include/net/netns/ipv6.h b/include/net/netns/ipv6.h
index 499e4288170f..83ac9c82d7dc 100644
--- a/include/net/netns/ipv6.h
+++ b/include/net/netns/ipv6.h
@@ -112,6 +112,7 @@ struct netns_ipv6 {
struct list_head mr6_tables;
struct fib_rules_ops *mr6_rules_ops;
#endif
+ struct mutex mfc_mutex;
#endif
atomic_t dev_addr_genid;
atomic_t fib6_sernum;
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index a31e3b740581..67385de7befe 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -1259,7 +1259,6 @@ static int ip6mr_mfc_delete(struct mr_table *mrt, struct mf6cctl *mfc,
{
struct mfc6_cache *c;
- /* The entries are added/deleted only under RTNL */
rcu_read_lock();
c = ip6mr_cache_find_parent(mrt, &mfc->mf6cc_origin.sin6_addr,
&mfc->mf6cc_mcastgrp.sin6_addr, parent);
@@ -1349,6 +1348,8 @@ static int __net_init ip6mr_net_init(struct net *net)
LIST_HEAD(dev_kill_list);
int err;
+ mutex_init(&net->ipv6.mfc_mutex);
+
err = ip6mr_notifier_init(net);
if (err)
return err;
@@ -1477,7 +1478,6 @@ static int ip6mr_mfc_add(struct net *net, struct mr_table *mrt,
ttls[i] = 1;
}
- /* The entries are added/deleted only under RTNL */
rcu_read_lock();
c = ip6mr_cache_find_parent(mrt, &mfc->mf6cc_origin.sin6_addr,
&mfc->mf6cc_mcastgrp.sin6_addr, parent);
@@ -1555,6 +1555,7 @@ static int ip6mr_mfc_add(struct net *net, struct mr_table *mrt,
static void mroute_clean_tables(struct mr_table *mrt, int flags,
struct list_head *dev_kill_list)
{
+ struct net *net = read_pnet(&mrt->net);
struct mr_mfc *c, *tmp;
int i;
@@ -1571,18 +1572,21 @@ static void mroute_clean_tables(struct mr_table *mrt, int flags,
/* Wipe the cache */
if (flags & (MRT6_FLUSH_MFC | MRT6_FLUSH_MFC_STATIC)) {
+ mutex_lock(&net->ipv6.mfc_mutex);
+
list_for_each_entry_safe(c, tmp, &mrt->mfc_cache_list, list) {
if (((c->mfc_flags & MFC_STATIC) && !(flags & MRT6_FLUSH_MFC_STATIC)) ||
(!(c->mfc_flags & MFC_STATIC) && !(flags & MRT6_FLUSH_MFC)))
continue;
rhltable_remove(&mrt->mfc_hash, &c->mnode, ip6mr_rht_params);
list_del_rcu(&c->list);
- call_ip6mr_mfc_entry_notifiers(read_pnet(&mrt->net),
- FIB_EVENT_ENTRY_DEL,
+ call_ip6mr_mfc_entry_notifiers(net, FIB_EVENT_ENTRY_DEL,
(struct mfc6_cache *)c, mrt->id);
mr6_netlink_event(mrt, (struct mfc6_cache *)c, RTM_DELROUTE);
mr_cache_put(c);
}
+
+ mutex_unlock(&net->ipv6.mfc_mutex);
}
if (flags & MRT6_FLUSH_MFC) {
@@ -1765,15 +1769,18 @@ int ip6_mroute_setsockopt(struct sock *sk, int optname, sockptr_t optval,
return -EFAULT;
if (parent == 0)
parent = mfc.mf6cc_parent;
- rtnl_lock();
+
+ mutex_lock(&net->ipv6.mfc_mutex);
+
if (optname == MRT6_DEL_MFC || optname == MRT6_DEL_MFC_PROXY)
ret = ip6mr_mfc_delete(mrt, &mfc, parent);
else
ret = ip6mr_mfc_add(net, mrt, &mfc,
sk ==
- rtnl_dereference(mrt->mroute_sk),
+ rcu_access_pointer(mrt->mroute_sk),
parent);
- rtnl_unlock();
+
+ mutex_unlock(&net->ipv6.mfc_mutex);
return ret;
case MRT6_FLUSH:
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
* [PATCH v2 net-next 14/15] ip6mr: Call fib_rules_unregister() without RTNL.
From: Kuniyuki Iwashima @ 2026-04-10 21:17 UTC (permalink / raw)
To: David S . Miller, David Ahern, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Simon Horman, Kuniyuki Iwashima, Kuniyuki Iwashima, netdev
In-Reply-To: <20260410211726.1668756-1-kuniyu@google.com>
fib_rules_unregister() removes ops from net->rules_ops under
spinlock, calls ops->delete() for each rule, and frees the ops.
ip6mr_rules_ops_template does not have ->delete(), and any
operation does not require RTNL there.
Let's move fib_rules_unregister() from ip6mr_rules_exit_rtnl()
to ip6mr_net_exit().
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
---
net/ipv6/ip6mr.c | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6mr.c b/net/ipv6/ip6mr.c
index 3b8867e150fe..a31e3b740581 100644
--- a/net/ipv6/ip6mr.c
+++ b/net/ipv6/ip6mr.c
@@ -259,6 +259,11 @@ static int __net_init ip6mr_rules_init(struct net *net)
return err;
}
+static void __net_exit ip6mr_rules_exit(struct net *net)
+{
+ fib_rules_unregister(net->ipv6.mr6_rules_ops);
+}
+
static void __net_exit ip6mr_rules_exit_rtnl(struct net *net,
struct list_head *dev_kill_list)
{
@@ -268,8 +273,6 @@ static void __net_exit ip6mr_rules_exit_rtnl(struct net *net,
list_del_rcu(&mrt->list);
ip6mr_free_table(mrt, dev_kill_list);
}
-
- fib_rules_unregister(net->ipv6.mr6_rules_ops);
}
static int ip6mr_rules_dump(struct net *net, struct notifier_block *nb,
@@ -329,6 +332,10 @@ static int __net_init ip6mr_rules_init(struct net *net)
return 0;
}
+static void __net_exit ip6mr_rules_exit(struct net *net)
+{
+}
+
static void __net_exit ip6mr_rules_exit_rtnl(struct net *net,
struct list_head *dev_kill_list)
{
@@ -1367,6 +1374,7 @@ static int __net_init ip6mr_net_init(struct net *net)
remove_proc_entry("ip6_mr_vif", net->proc_net);
proc_vif_fail:
ip6mr_rules_exit_rtnl(net, &dev_kill_list);
+ ip6mr_rules_exit(net);
#endif
ip6mr_rules_fail:
ip6mr_notifier_exit(net);
@@ -1379,6 +1387,7 @@ static void __net_exit ip6mr_net_exit(struct net *net)
remove_proc_entry("ip6_mr_cache", net->proc_net);
remove_proc_entry("ip6_mr_vif", net->proc_net);
#endif
+ ip6mr_rules_exit(net);
ip6mr_notifier_exit(net);
}
--
2.53.0.1213.gd9a14994de-goog
^ permalink raw reply related
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