* Re: [PATCH net-next v4] virtio-net: enable NETIF_F_GRO_HW only if GRO-related offloads are supported
From: Jakub Kicinski @ 2026-03-27 3:03 UTC (permalink / raw)
To: mst, jasowang
Cc: Di Zhu, xuanzhuo, eperezma, andrew+netdev, davem, edumazet,
pabeni, willemb, netdev, virtualization, lijing, yingzhiwei
In-Reply-To: <20260323041730.986351-1-zhud@hygon.cn>
On Mon, 23 Mar 2026 12:17:30 +0800 Di Zhu wrote:
> Negotiating VIRTIO_NET_F_CTRL_GUEST_OFFLOADS indicates the device
> allows control over offload support, but the offloads that can be
> controlled may have nothing to do with GRO (e.g., if neither GUEST_TSO4
> nor GUEST_TSO6 is supported).
>
> In such a setup, reporting NETIF_F_GRO_HW as available for the device
> is too optimistic and misleading to the user.
>
> Improve the situation by masking off NETIF_F_GRO_HW unless the device
> possesses actual GRO-related offload capabilities. Out of an abundance
> of caution, this does not change the current behaviour for hardware with
> just v6 or just v4 GRO: current interfaces do not allow distinguishing
> between v6/v4 GRO, so we can't expose them to userspace precisely.
Michael, Jason, does this patch look good now?
https://lore.kernel.org/all/20260323041730.986351-1-zhud@hygon.cn/
^ permalink raw reply
* Re: [PATCH net-next] net: airoha: Grab flow_offload_mutex running airoha_register_gdm_devices()
From: Jakub Kicinski @ 2026-03-27 3:06 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260324-airoha-regiser-race-fix-v1-1-6014df55886b@kernel.org>
On Tue, 24 Mar 2026 17:54:45 +0100 Lorenzo Bianconi wrote:
> Netfilter flowtable can theoretically try offload flower rules as soon
> as a net-device is registered while not all the other ones are
> registered/initialized, triggering a possible NULL pointer dereferencing
> of qdma pointer in airoha_ppe_set_cpu_port routine. In order to avoid any
> possible race, grab the flow_offload_mutex running
> airoha_register_gdm_devices().
Sashiko says this causes a lock ordering issue:
https://sashiko.dev/#/patchset/20260324-airoha-regiser-race-fix-v1-1-6014df55886b@kernel.org
^ permalink raw reply
* Re: [PATCH net-next] virtio_net: sync RX buffer before reading the header
From: Jakub Kicinski @ 2026-03-27 3:07 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Simon Horman, linux-kernel, Omar Elghoul, Srikanth Aithal,
Jason Wang, Xuan Zhuo, Eugenio Pérez, Andrew Lunn,
David S. Miller, Eric Dumazet, Paolo Abeni, Alexei Starovoitov,
Daniel Borkmann, Jesper Dangaard Brouer, John Fastabend,
Stanislav Fomichev, Vishwanath Seshagiri, netdev, virtualization,
bpf
In-Reply-To: <20260326180313-mutt-send-email-mst@kernel.org>
On Thu, 26 Mar 2026 18:03:28 -0400 Michael S. Tsirkin wrote:
> > The hash for a patch with that subject in net-next appears to be 24fbd3967f3f.
>
> Thanks, will fix in the next version.
Don't worry, I'll correct when applying
^ permalink raw reply
* Re: [PATCH v2 0/7] J722S SGMII support
From: Jakub Kicinski @ 2026-03-27 3:11 UTC (permalink / raw)
To: Nora Schiffer
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Nishanth Menon, Vignesh Raghavendra, Tero Kristo,
Siddharth Vadapalli, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Vinod Koul, Neil Armstrong, netdev, devicetree,
linux-kernel, linux-phy, linux-arm-kernel, linux
In-Reply-To: <cover.1774354734.git.nora.schiffer@ew.tq-group.com>
On Tue, 24 Mar 2026 13:29:36 +0100 Nora Schiffer wrote:
> The J722S CPSW and SERDES are very similar to the variants found on the
> AM64, but they additionally support SGMII. Introduce new compatible
> strings for the J722S to add this support to the drivers.
>
> This is a prerequisite for the Single-Pair Ethernet interface of the
> TQ-Systems MBa67xx baseboard for the TQMa67xx SoM, which will be
> submitted separately.
Please repost patch 3+6 as a separate series for net-next.
^ permalink raw reply
* Re: [PATCH net-next v2] net: mana: Set default number of queues to 16
From: Jakub Kicinski @ 2026-03-27 3:18 UTC (permalink / raw)
To: Long Li
Cc: Konstantin Taranov, David S . Miller, Paolo Abeni, Eric Dumazet,
Andrew Lunn, Jason Gunthorpe, Leon Romanovsky, Haiyang Zhang,
K . Y . Srinivasan, Wei Liu, Dexuan Cui, Simon Horman, netdev,
linux-rdma, linux-hyperv, linux-kernel
In-Reply-To: <20260323194925.1766385-1-longli@microsoft.com>
On Mon, 23 Mar 2026 12:49:25 -0700 Long Li wrote:
> Set the default number of queues per vPort to MANA_DEF_NUM_QUEUES (16),
> as 16 queues can achieve optimal throughput for typical workloads. The
> actual number of queues may be lower if it exceeds the hardware reported
> limit. Users can increase the number of queues up to max_queues via
> ethtool if needed.
Sorry we are a bit backlogged I didn't spot this in time (read: I'm
planning to revert this unless proper explanation is provided)
Could you explain why not use netif_get_num_default_rss_queues() ?
Having local driver innovations is a major PITA for users who deal
with heterogeneous envs.
^ permalink raw reply
* Re: [PATCH net v3 1/1] net: fec: fix the PTP periodic output sysfs interface
From: patchwork-bot+netdevbpf @ 2026-03-27 3:20 UTC (permalink / raw)
To: Buday Csaba
Cc: wei.fang, frank.li, shenwei.wang, andrew+netdev, davem, edumazet,
kuba, pabeni, richardcochran, francesco.dolcini, bence98, imx,
netdev, linux-kernel
In-Reply-To: <8ec2afe88423c2231f9cf8044d212ce57846670e.1774359059.git.buday.csaba@prolan.hu>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 24 Mar 2026 14:32:30 +0100 you wrote:
> When the PPS channel configuration was implemented, the channel
> index for the periodic outputs was configured as the hardware
> channel number.
>
> The sysfs interface uses a logical channel index, and rejects numbers
> greater than `n_per_out` (see period_store() in ptp_sysfs.c).
> That property was left at 1, since the driver implements channel
> selection, not simultaneous operation of multiple PTP hardware timer
> channels.
>
> [...]
Here is the summary with links:
- [net,v3,1/1] net: fec: fix the PTP periodic output sysfs interface
https://git.kernel.org/netdev/net/c/e8e44c98f789
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] netdevsim: fix build if SKB_EXTENSIONS=n
From: patchwork-bot+netdevbpf @ 2026-03-27 3:20 UTC (permalink / raw)
To: Qingfang Deng
Cc: davem, edumazet, kuba, pabeni, horms, atwellwea, daniel.zahka,
netdev, linux-kernel
In-Reply-To: <20260324140857.783-1-dqfext@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 24 Mar 2026 22:08:56 +0800 you wrote:
> __skb_ext_put() is not declared if SKB_EXTENSIONS is not enabled, which
> causes a build error:
>
> drivers/net/netdevsim/netdev.c: In function 'nsim_forward_skb':
> drivers/net/netdevsim/netdev.c:114:25: error: implicit declaration of function '__skb_ext_put'; did you mean 'skb_ext_put'? [-Werror=implicit-function-declaration]
> 114 | __skb_ext_put(psp_ext);
> | ^~~~~~~~~~~~~
> | skb_ext_put
> cc1: some warnings being treated as errors
>
> [...]
Here is the summary with links:
- [net] netdevsim: fix build if SKB_EXTENSIONS=n
https://git.kernel.org/netdev/net/c/57a04a13aac1
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] tcp: tcp_vegas: use tcp_vegas_cwnd_event_tx_start()
From: patchwork-bot+netdevbpf @ 2026-03-27 3:20 UTC (permalink / raw)
To: Eric Dumazet
Cc: davem, kuba, pabeni, horms, ncardwell, kuniyu, willemb, netdev,
eric.dumazet
In-Reply-To: <20260325212440.4146579-1-edumazet@google.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 25 Mar 2026 21:24:39 +0000 you wrote:
> While net/ipv4/tcp_yeah.c is correctly setting .cwnd_event_tx_start
> to tcp_vegas_cwnd_event_tx_start(), I forgot to do the same in tcp_vegas.c
>
> Fixes: d1e59a469737 ("tcp: add cwnd_event_tx_start to tcp_congestion_ops")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> net/ipv4/tcp_vegas.c | 1 +
> 1 file changed, 1 insertion(+)
Here is the summary with links:
- [net-next] tcp: tcp_vegas: use tcp_vegas_cwnd_event_tx_start()
https://git.kernel.org/netdev/net-next/c/6a539eee855c
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] virtio_net: sync RX buffer before reading the header
From: patchwork-bot+netdevbpf @ 2026-03-27 3:20 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: linux-kernel, oelghoul, sraithal, jasowang, xuanzhuo, eperezma,
andrew+netdev, davem, edumazet, kuba, pabeni, ast, daniel, hawk,
john.fastabend, sdf, vishs, netdev, virtualization, bpf
In-Reply-To: <f4caa9be9e5addae7851c012cab0a733be7f0974.1774365273.git.mst@redhat.com>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 24 Mar 2026 11:15:54 -0400 you wrote:
> receive_buf() reads the virtio header through buf before
> page_pool_dma_sync_for_cpu() runs in receive_small() or
> receive_mergeable(). The header buffer is thus unsynchronized at the
> point where flags and, for mergeable buffers, num_buffers are consumed.
>
> Omar Elghoul reported that on s390x Secure Execution this showed up as
> greatly reduced virtio-net performance together with "bad gso" and
> "bad csum" messages in dmesg. This is because with SE sync actually
> copies data, so the header is uninitialized.
>
> [...]
Here is the summary with links:
- [net-next] virtio_net: sync RX buffer before reading the header
https://git.kernel.org/netdev/net-next/c/fe3e54253f0b
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] virtio-net: enable NETIF_F_GRO_HW only if GRO-related offloads are supported
From: Jason Wang @ 2026-03-27 3:22 UTC (permalink / raw)
To: Di Zhu
Cc: mst, xuanzhuo, eperezma, andrew+netdev, davem, edumazet, kuba,
pabeni, willemb, netdev, virtualization, lijing, yingzhiwei
In-Reply-To: <20260323041730.986351-1-zhud@hygon.cn>
On Mon, Mar 23, 2026 at 12:18 PM Di Zhu <zhud@hygon.cn> wrote:
>
> Negotiating VIRTIO_NET_F_CTRL_GUEST_OFFLOADS indicates the device
> allows control over offload support, but the offloads that can be
> controlled may have nothing to do with GRO (e.g., if neither GUEST_TSO4
> nor GUEST_TSO6 is supported).
>
> In such a setup, reporting NETIF_F_GRO_HW as available for the device
> is too optimistic and misleading to the user.
>
> Improve the situation by masking off NETIF_F_GRO_HW unless the device
> possesses actual GRO-related offload capabilities. Out of an abundance
> of caution, this does not change the current behaviour for hardware with
> just v6 or just v4 GRO: current interfaces do not allow distinguishing
> between v6/v4 GRO, so we can't expose them to userspace precisely.
>
> Signed-off-by: Di Zhu <zhud@hygon.cn>
> ---
> /* v4 */
> -Move the hw_features update logic before register_netdevice()
> -Target the net-next tree
>
> /* v3 */
> -Update Fixes tag to dbcf24d15388
> -Refine commit message using Maintainer's "too optimistic"
> phrasing to clarify the risk of misleading configurations.
>
> /* v2 */
> -make the modified logic clearer
Acked-by: Jason Wang <jasowang@redhat.com>
Thanks
^ permalink raw reply
* Re: [PATCH net-next v4] virtio-net: enable NETIF_F_GRO_HW only if GRO-related offloads are supported
From: Jason Wang @ 2026-03-27 3:22 UTC (permalink / raw)
To: Jakub Kicinski
Cc: mst, Di Zhu, xuanzhuo, eperezma, andrew+netdev, davem, edumazet,
pabeni, willemb, netdev, virtualization, lijing, yingzhiwei
In-Reply-To: <20260326200346.438702a6@kernel.org>
On Fri, Mar 27, 2026 at 11:03 AM Jakub Kicinski <kuba@kernel.org> wrote:
>
> On Mon, 23 Mar 2026 12:17:30 +0800 Di Zhu wrote:
> > Negotiating VIRTIO_NET_F_CTRL_GUEST_OFFLOADS indicates the device
> > allows control over offload support, but the offloads that can be
> > controlled may have nothing to do with GRO (e.g., if neither GUEST_TSO4
> > nor GUEST_TSO6 is supported).
> >
> > In such a setup, reporting NETIF_F_GRO_HW as available for the device
> > is too optimistic and misleading to the user.
> >
> > Improve the situation by masking off NETIF_F_GRO_HW unless the device
> > possesses actual GRO-related offload capabilities. Out of an abundance
> > of caution, this does not change the current behaviour for hardware with
> > just v6 or just v4 GRO: current interfaces do not allow distinguishing
> > between v6/v4 GRO, so we can't expose them to userspace precisely.
>
> Michael, Jason, does this patch look good now?
>
> https://lore.kernel.org/all/20260323041730.986351-1-zhud@hygon.cn/
>
Yes, I've acked.
Thanks
^ permalink raw reply
* Re: [PATCH v3 net 0/8] xsk: tailroom reservation and MTU validation
From: Jakub Kicinski @ 2026-03-27 3:27 UTC (permalink / raw)
To: Maciej Fijalkowski
Cc: netdev, bpf, magnus.karlsson, stfomichev, pabeni, horms,
larysa.zaremba, aleksander.lobakin, bjorn, Ihor Solodrai
In-Reply-To: <20260323192457.504631-1-maciej.fijalkowski@intel.com>
On Mon, 23 Mar 2026 20:24:49 +0100 Maciej Fijalkowski wrote:
> here we fix a long-standing issue regarding multi-buffer scenario in ZC
> mode - we have not been providing space at the end of the buffer where
> multi-buffer XDP works on skb_shared_info. This has been brought to our
> attention via [0].
>
> Unaligned mode does not get any specific treatment, it is user's
> responsibility to properly handle XSK addresses in queues.
>
> With adjustments included here in this set against xskxceiver I have
> been able to pass the full test suite on ice.
Please scream at me if I'm wrong but I _think_ this is somehow
breaking BPF CI ?? It's the only BPF change we have AFAICT and
CI has been failing like this all day:
Root directory input is valid!
Error: The path for one of the files in artifact is not valid: /packets-132-3-net_timestamping__INET4:_bpf_timestamping-net_timestamping_ns.log. Contains the following character: Colon :
Invalid characters include: Double quote ", Colon :, Less than <, Greater than >, Vertical bar |, Asterisk *, Question mark ?, Carriage return \r, Line feed \n
https://github.com/kernel-patches/bpf/actions/runs/23624136123/job/68809559810
^ permalink raw reply
* Re: [PATCH net-next v4] virtio-net: enable NETIF_F_GRO_HW only if GRO-related offloads are supported
From: Jakub Kicinski @ 2026-03-27 3:29 UTC (permalink / raw)
To: Jason Wang
Cc: mst, Di Zhu, xuanzhuo, eperezma, andrew+netdev, davem, edumazet,
pabeni, willemb, netdev, virtualization, lijing, yingzhiwei
In-Reply-To: <CACGkMEshcxj-R1Ek1dRykBTQ6NLS11jt-9NAu8PbcmtzobRY0g@mail.gmail.com>
On Fri, 27 Mar 2026 11:22:43 +0800 Jason Wang wrote:
> On Fri, Mar 27, 2026 at 11:03 AM Jakub Kicinski <kuba@kernel.org> wrote:
> >
> > On Mon, 23 Mar 2026 12:17:30 +0800 Di Zhu wrote:
> > > Negotiating VIRTIO_NET_F_CTRL_GUEST_OFFLOADS indicates the device
> > > allows control over offload support, but the offloads that can be
> > > controlled may have nothing to do with GRO (e.g., if neither GUEST_TSO4
> > > nor GUEST_TSO6 is supported).
> > >
> > > In such a setup, reporting NETIF_F_GRO_HW as available for the device
> > > is too optimistic and misleading to the user.
> > >
> > > Improve the situation by masking off NETIF_F_GRO_HW unless the device
> > > possesses actual GRO-related offload capabilities. Out of an abundance
> > > of caution, this does not change the current behaviour for hardware with
> > > just v6 or just v4 GRO: current interfaces do not allow distinguishing
> > > between v6/v4 GRO, so we can't expose them to userspace precisely.
> >
> > Michael, Jason, does this patch look good now?
> >
> > https://lore.kernel.org/all/20260323041730.986351-1-zhud@hygon.cn/
> >
>
> Yes, I've acked.
Obrigado!
^ permalink raw reply
* [PATCH net] rtase: Fix flow control configuration
From: Justin Lai @ 2026-03-27 3:29 UTC (permalink / raw)
To: kuba
Cc: davem, edumazet, pabeni, andrew+netdev, linux-kernel, netdev,
horms, pkshih, larry.chiu, Justin Lai
Fix hardware setting to allow flow control to be configured via
ethtool.
Fixes: 85dd839ad1e5 ("rtase: Implement hardware configuration function")
Signed-off-by: Justin Lai <justinlai0215@realtek.com>
---
drivers/net/ethernet/realtek/rtase/rtase.h | 4 ++++
drivers/net/ethernet/realtek/rtase/rtase_main.c | 3 +++
2 files changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/realtek/rtase/rtase.h b/drivers/net/ethernet/realtek/rtase/rtase.h
index b9209eb6ea73..9bd6872474c1 100644
--- a/drivers/net/ethernet/realtek/rtase/rtase.h
+++ b/drivers/net/ethernet/realtek/rtase/rtase.h
@@ -153,6 +153,10 @@ enum rtase_registers {
#define RTASE_FORCE_TXFLOW_EN BIT(10)
#define RTASE_RX_CHKSUM BIT(5)
+ RTASE_GPHY_STD_00 = 0x6024,
+#define RTASE_RXFLOW_EN BIT(7)
+#define RTASE_TXFLOW_EN BIT(6)
+
RTASE_Q0_RX_DESC_ADDR0 = 0x00E4,
RTASE_Q0_RX_DESC_ADDR4 = 0x00E8,
RTASE_Q1_RX_DESC_ADDR0 = 0x4000,
diff --git a/drivers/net/ethernet/realtek/rtase/rtase_main.c b/drivers/net/ethernet/realtek/rtase/rtase_main.c
index ef13109c49cf..bde9bccfb5a9 100644
--- a/drivers/net/ethernet/realtek/rtase/rtase_main.c
+++ b/drivers/net/ethernet/realtek/rtase/rtase_main.c
@@ -974,6 +974,9 @@ static void rtase_hw_config(struct net_device *dev)
rtase_hw_set_features(dev, dev->features);
/* enable flow control */
+ reg_data16 = rtase_r16(tp, RTASE_GPHY_STD_00);
+ reg_data16 &= ~(RTASE_TXFLOW_EN | RTASE_RXFLOW_EN);
+ rtase_w16(tp, RTASE_GPHY_STD_00, reg_data16);
reg_data16 = rtase_r16(tp, RTASE_CPLUS_CMD);
reg_data16 |= (RTASE_FORCE_TXFLOW_EN | RTASE_FORCE_RXFLOW_EN);
rtase_w16(tp, RTASE_CPLUS_CMD, reg_data16);
--
2.40.1
^ permalink raw reply related
* Re: [PATCH v5 RESEND net 0/3] net: enetc: safely reinitialize TX BD ring when it has unsent frames
From: patchwork-bot+netdevbpf @ 2026-03-27 3:30 UTC (permalink / raw)
To: Wei Fang
Cc: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, linux, Frank.Li, horms,
saikrishnag, netdev, linux-kernel, imx
In-Reply-To: <20260324062121.2745033-1-wei.fang@nxp.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 24 Mar 2026 14:21:18 +0800 you wrote:
> Currently the driver does not reset the producer index register (PIR) and
> consumer index register (CIR) when initializing a TX BD ring. The driver
> only reads the PIR and CIR and initializes the software indexes. If the
> TX BD ring is reinitialized when it still contains unsent frames, its PIR
> and CIR will not be equal after the reinitialization. However, the BDs
> between CIR and PIR have been freed and become invalid and this can lead
> to a hardware malfunction, causing the TX BD ring will not work properly.
>
> [...]
Here is the summary with links:
- [v5,RESEND,net,1/3] net: enetc: reset PIR and CIR if they are not equal when initializing TX ring
https://git.kernel.org/netdev/net/c/0239fd701d33
- [v5,RESEND,net,2/3] net: enetc: add graceful stop to safely reinitialize the TX Ring
https://git.kernel.org/netdev/net/c/2725d84efe25
- [v5,RESEND,net,3/3] net: enetc: do not access non-existent registers on pseudo MAC
https://git.kernel.org/netdev/net/c/f2df9567b123
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 v2 0/2] Add support for PIC64-HPSC/HX MDIO controller
From: Jakub Kicinski @ 2026-03-27 3:33 UTC (permalink / raw)
To: Charles Perry
Cc: netdev, Andrew Lunn, David S. Miller, Eric Dumazet, Paolo Abeni,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiner Kallweit,
Russell King, devicetree, linux-kernel
In-Reply-To: <20260323220254.3822444-1-charles.perry@microchip.com>
On Mon, 23 Mar 2026 15:02:52 -0700 Charles Perry wrote:
> .../net/microchip,pic64hpsc-mdio.yaml | 68 +++++++
> drivers/net/mdio/Kconfig | 7 +
> drivers/net/mdio/Makefile | 1 +
> drivers/net/mdio/mdio-pic64hpsc.c | 192 ++++++++++++++++++
Speaking under correction from PHY maintainers but I think we need
a MAINTAINERS entry that will cover Microchip MDIO, or at least the
files you're adding. Important read:
https://docs.kernel.org/next/maintainer/feature-and-driver-maintainers.html
--
pw-bot: cr
^ permalink raw reply
* [PATCH net-next v6] selftests: net: add tests for PPP
From: Qingfang Deng @ 2026-03-27 3:34 UTC (permalink / raw)
To: Shuah Khan, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Felix Maurer,
Sebastian Andrzej Siewior, Antonio Quartulli, Petr Machata,
linux-kernel, linux-kselftest, linux-ppp, netdev
Cc: Paul Mackerras
Add ping and iperf3 tests for ppp_async.c and pppoe.c.
Signed-off-by: Qingfang Deng <dqfext@gmail.com>
---
v6: fix SC2329 scope
https://lore.kernel.org/netdev/20260327024202.111655-1-dqfext@gmail.com/
MAINTAINERS | 1 +
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/net/ppp/Makefile | 15 +++++++
tools/testing/selftests/net/ppp/config | 9 ++++
tools/testing/selftests/net/ppp/ppp_async.sh | 44 +++++++++++++++++++
tools/testing/selftests/net/ppp/ppp_common.sh | 44 +++++++++++++++++++
.../selftests/net/ppp/pppoe-server-options | 2 +
tools/testing/selftests/net/ppp/pppoe.sh | 41 +++++++++++++++++
8 files changed, 157 insertions(+)
create mode 100644 tools/testing/selftests/net/ppp/Makefile
create mode 100644 tools/testing/selftests/net/ppp/config
create mode 100755 tools/testing/selftests/net/ppp/ppp_async.sh
create mode 100644 tools/testing/selftests/net/ppp/ppp_common.sh
create mode 100644 tools/testing/selftests/net/ppp/pppoe-server-options
create mode 100755 tools/testing/selftests/net/ppp/pppoe.sh
diff --git a/MAINTAINERS b/MAINTAINERS
index 7a2ffd9d37d5..b922e154b9e7 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21080,6 +21080,7 @@ PPP PROTOCOL DRIVERS AND COMPRESSORS
L: linux-ppp@vger.kernel.org
S: Orphan
F: drivers/net/ppp/ppp_*
+F: tools/testing/selftests/net/ppp/
PPS SUPPORT
M: Rodolfo Giometti <giometti@enneenne.com>
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 450f13ba4cca..65f84e8a0cf0 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -78,6 +78,7 @@ TARGETS += net/netfilter
TARGETS += net/openvswitch
TARGETS += net/ovpn
TARGETS += net/packetdrill
+TARGETS += net/ppp
TARGETS += net/rds
TARGETS += net/tcp_ao
TARGETS += nolibc
diff --git a/tools/testing/selftests/net/ppp/Makefile b/tools/testing/selftests/net/ppp/Makefile
new file mode 100644
index 000000000000..b39b0abadde6
--- /dev/null
+++ b/tools/testing/selftests/net/ppp/Makefile
@@ -0,0 +1,15 @@
+# SPDX-License-Identifier: GPL-2.0
+
+top_srcdir = ../../../../..
+
+TEST_PROGS := \
+ ppp_async.sh \
+ pppoe.sh \
+# end of TEST_PROGS
+
+TEST_FILES := \
+ ppp_common.sh \
+ pppoe-server-options \
+# end of TEST_FILES
+
+include ../../lib.mk
diff --git a/tools/testing/selftests/net/ppp/config b/tools/testing/selftests/net/ppp/config
new file mode 100644
index 000000000000..b45d25c5b970
--- /dev/null
+++ b/tools/testing/selftests/net/ppp/config
@@ -0,0 +1,9 @@
+CONFIG_IPV6=y
+CONFIG_PACKET=y
+CONFIG_PPP=m
+CONFIG_PPP_ASYNC=m
+CONFIG_PPP_BSDCOMP=m
+CONFIG_PPP_DEFLATE=m
+CONFIG_PPPOE=m
+CONFIG_PPPOE_HASH_BITS_4=y
+CONFIG_VETH=y
diff --git a/tools/testing/selftests/net/ppp/ppp_async.sh b/tools/testing/selftests/net/ppp/ppp_async.sh
new file mode 100755
index 000000000000..9233dc656678
--- /dev/null
+++ b/tools/testing/selftests/net/ppp/ppp_async.sh
@@ -0,0 +1,44 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+source ppp_common.sh
+
+# Temporary files for PTY symlinks
+TTY_DIR=$(mktemp -d /tmp/ppp.XXXXXX)
+TTY_SERVER="$TTY_DIR"/server
+TTY_CLIENT="$TTY_DIR"/client
+
+# shellcheck disable=SC2329
+cleanup() {
+ cleanup_all_ns
+ [ -n "$SOCAT_PID" ] && kill_process "$SOCAT_PID"
+ rm -fr "$TTY_DIR"
+}
+
+trap cleanup EXIT
+
+require_command socat
+ppp_common_init
+modprobe -q ppp_async
+
+# Create the virtual serial device
+socat -d PTY,link="$TTY_SERVER",rawer PTY,link="$TTY_CLIENT",rawer &
+SOCAT_PID=$!
+
+# Wait for symlinks to be created
+slowwait 5 [ -L "$TTY_SERVER" ]
+
+# Start the PPP Server
+ip netns exec "$NS_SERVER" pppd "$TTY_SERVER" 115200 \
+ "$IP_SERVER":"$IP_CLIENT" \
+ local noauth nodefaultroute debug
+
+# Start the PPP Client
+ip netns exec "$NS_CLIENT" pppd "$TTY_CLIENT" 115200 \
+ local noauth updetach nodefaultroute debug
+
+ppp_test_connectivity
+
+log_test "PPP async"
+
+exit "$EXIT_STATUS"
diff --git a/tools/testing/selftests/net/ppp/ppp_common.sh b/tools/testing/selftests/net/ppp/ppp_common.sh
new file mode 100644
index 000000000000..c72218813f95
--- /dev/null
+++ b/tools/testing/selftests/net/ppp/ppp_common.sh
@@ -0,0 +1,44 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+# shellcheck disable=SC2153
+
+source ../lib.sh
+
+IP_SERVER="192.168.200.1"
+IP_CLIENT="192.168.200.2"
+
+ppp_common_init() {
+ # Package requirements
+ require_command pppd
+ require_command iperf3
+
+ # Check for root privileges
+ if [ "$(id -u)" -ne 0 ];then
+ echo "SKIP: Need root privileges"
+ exit $ksft_skip
+ fi
+
+ # Namespaces
+ setup_ns NS_SERVER NS_CLIENT
+}
+
+ppp_check_addr() {
+ dev=$1
+ addr=$2
+ ns=$3
+ ip -netns "$ns" -4 addr show dev "$dev" 2>/dev/null | grep -q "$addr"
+ return $?
+}
+
+ppp_test_connectivity() {
+ slowwait 10 ppp_check_addr "ppp0" "$IP_CLIENT" "$NS_CLIENT"
+
+ ip netns exec "$NS_CLIENT" ping -c 3 "$IP_SERVER"
+ check_err $?
+
+ ip netns exec "$NS_SERVER" iperf3 -s -1 -D
+ wait_local_port_listen "$NS_SERVER" 5201 tcp
+
+ ip netns exec "$NS_CLIENT" iperf3 -c "$IP_SERVER" -Z -t 2
+ check_err $?
+}
diff --git a/tools/testing/selftests/net/ppp/pppoe-server-options b/tools/testing/selftests/net/ppp/pppoe-server-options
new file mode 100644
index 000000000000..66c8c9d319e9
--- /dev/null
+++ b/tools/testing/selftests/net/ppp/pppoe-server-options
@@ -0,0 +1,2 @@
+noauth
+noipdefault
diff --git a/tools/testing/selftests/net/ppp/pppoe.sh b/tools/testing/selftests/net/ppp/pppoe.sh
new file mode 100755
index 000000000000..73e4ea957b43
--- /dev/null
+++ b/tools/testing/selftests/net/ppp/pppoe.sh
@@ -0,0 +1,41 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0
+
+source ppp_common.sh
+
+VETH_SERVER="veth-server"
+VETH_CLIENT="veth-client"
+
+# shellcheck disable=SC2329
+cleanup() {
+ cleanup_all_ns
+}
+
+trap cleanup EXIT
+
+require_command pppoe-server
+ppp_common_init
+modprobe -q pppoe
+
+# Create the veth pair
+ip link add "$VETH_SERVER" type veth peer name "$VETH_CLIENT"
+ip link set "$VETH_SERVER" netns "$NS_SERVER"
+ip link set "$VETH_CLIENT" netns "$NS_CLIENT"
+ip -netns "$NS_SERVER" link set "$VETH_SERVER" up
+ip -netns "$NS_CLIENT" link set "$VETH_CLIENT" up
+
+# Start the PPP Server
+ip netns exec "$NS_SERVER" pppoe-server -I "$VETH_SERVER" \
+ -L "$IP_SERVER" -R "$IP_CLIENT" -N 1 -q "$(command -v pppd)" \
+ -k -O "$(pwd)/pppoe-server-options"
+
+# Start the PPP Client
+ip netns exec "$NS_CLIENT" pppd \
+ local debug updetach noipdefault noauth nodefaultroute \
+ plugin pppoe.so nic-"$VETH_CLIENT"
+
+ppp_test_connectivity
+
+log_test "PPPoE"
+
+exit "$EXIT_STATUS"
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] rtnetlink: add missing netlink_ns_capable() check for peer netns
From: Jakub Kicinski @ 2026-03-27 3:36 UTC (permalink / raw)
To: Nikolaos Gkarlis; +Cc: netdev
In-Reply-To: <20260324080730.4051666-1-nickgarlis@gmail.com>
On Tue, 24 Mar 2026 09:07:30 +0100 Nikolaos Gkarlis wrote:
> rtnl_newlink() lacks a CAP_NET_ADMIN capability check on the peer
> network namespace when creating paired devices (veth, vxcan,
> netkit). This allows an unprivileged user with a user namespace
> to create interfaces in arbitrary network namespaces, including
> init_net.
>
> Add a netlink_ns_capable() check for CAP_NET_ADMIN in the peer
> namespace before allowing device creation to proceed.
>
> Fixes: 48327566769a ("rtnetlink: fix double call of rtnl_link_get_net_ifla()")
AI assistant here suggests this is not the valid Fixes tag,
which seems true on the surface. This commit was fixing
cleanup, IDK how it could break input validation?
> Reported-by: Nikolaos Gkarlis <nickgarlis@gmail.com>
Reported-by tags are only when the reporter is different than author
the Google's bounty program rules have been amended to make this
explicit, please let us know if other programs still mislead people
> Signed-off-by: Nikolaos Gkarlis <nickgarlis@gmail.com>
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net v1] net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory leak
From: patchwork-bot+netdevbpf @ 2026-03-27 3:40 UTC (permalink / raw)
To: Jiayuan Chen
Cc: netdev, jiayuan.chen, syzbot+006987d1be3586e13555, mani, davem,
edumazet, kuba, pabeni, horms, andersson, linux-arm-msm,
linux-kernel
In-Reply-To: <20260324080645.290197-1-jiayuan.chen@linux.dev>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 24 Mar 2026 16:06:44 +0800 you wrote:
> From: Jiayuan Chen <jiayuan.chen@shopee.com>
>
> __radix_tree_create() allocates and links intermediate nodes into the
> tree one by one. If a subsequent allocation fails, the already-linked
> nodes remain in the tree with no corresponding leaf entry. These orphaned
> internal nodes are never reclaimed because radix_tree_for_each_slot()
> only visits slots containing leaf values.
>
> [...]
Here is the summary with links:
- [net,v1] net: qrtr: replace qrtr_tx_flow radix_tree with xarray to fix memory leak
https://git.kernel.org/netdev/net/c/2428083101f6
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] virtio-net: enable NETIF_F_GRO_HW only if GRO-related offloads are supported
From: patchwork-bot+netdevbpf @ 2026-03-27 3:40 UTC (permalink / raw)
To: Di Zhu
Cc: mst, jasowang, xuanzhuo, eperezma, andrew+netdev, davem, edumazet,
kuba, pabeni, willemb, netdev, virtualization, lijing, yingzhiwei
In-Reply-To: <20260323041730.986351-1-zhud@hygon.cn>
Hello:
This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 23 Mar 2026 12:17:30 +0800 you wrote:
> Negotiating VIRTIO_NET_F_CTRL_GUEST_OFFLOADS indicates the device
> allows control over offload support, but the offloads that can be
> controlled may have nothing to do with GRO (e.g., if neither GUEST_TSO4
> nor GUEST_TSO6 is supported).
>
> In such a setup, reporting NETIF_F_GRO_HW as available for the device
> is too optimistic and misleading to the user.
>
> [...]
Here is the summary with links:
- [net-next,v4] virtio-net: enable NETIF_F_GRO_HW only if GRO-related offloads are supported
https://git.kernel.org/netdev/net-next/c/f8844dfeeae8
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH v2 net] ptr_ring: disable KCSAN warnings
From: Eric Dumazet @ 2026-03-27 3:43 UTC (permalink / raw)
To: Jason Wang
Cc: Michael S. Tsirkin, linux-kernel, bpf, Simon Schippers,
willemdebruijn.kernel, andrew+netdev, davem, kuba, pabeni,
eperezma, leiyang, stephen, jon, tim.gebauer, netdev, kvm,
virtualization
In-Reply-To: <CACGkMEuL613R8GRUX2hjRuJcvP0LNC_6_D1Y1yEjtTqehy6zJA@mail.gmail.com>
On Wed, Mar 25, 2026 at 8:17 PM Jason Wang <jasowang@redhat.com> wrote:
>
> On Thu, Mar 26, 2026 at 1:36 AM Michael S. Tsirkin <mst@redhat.com> wrote:
>
> Acked-by: Jason Wang <jasowang@redhat.com>
>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks!
^ permalink raw reply
* Re: [PATCH] net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak
From: patchwork-bot+netdevbpf @ 2026-03-27 3:50 UTC (permalink / raw)
To: Yochai Eisenrich; +Cc: davem, dsahern, security, netdev
In-Reply-To: <20260324224925.2437775-1-echelonh@gmail.com>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 25 Mar 2026 00:49:25 +0200 you wrote:
> When processing Router Advertisements with user options the kernel
> builds an RTM_NEWNDUSEROPT netlink message. The nduseroptmsg struct
> has three padding fields that are never zeroed and can leak kernel data
>
> The fix is simple, just zeroes the padding fields.
>
> Fixes: 31910575a9de ("[IPv6]: Export userland ND options through netlink
> (RDNSS support)")
> Signed-off-by: Yochai Eisenrich <echelonh@gmail.com>
>
> [...]
Here is the summary with links:
- net: ipv6: ndisc: fix ndisc_ra_useropt to initialize nduseropt_padX fields to zero to prevent an info-leak
https://git.kernel.org/netdev/net/c/ae05340ccaa9
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/2] net: stmmac: remove unused and unimplemented AXI properties
From: patchwork-bot+netdevbpf @ 2026-03-27 3:50 UTC (permalink / raw)
To: Russell King
Cc: andrew, alexandre.torgue, andrew+netdev, conor+dt, davem,
devicetree, edumazet, peppe.cavallaro, kuba, joabreu, krzk+dt,
linux-arm-kernel, linux-stm32, netdev, pabeni, robh, me
In-Reply-To: <acJh4z3pRKkeaFbR@shell.armlinux.org.uk>
Hello:
This series was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 24 Mar 2026 10:05:23 +0000 you wrote:
> commit afea03656add ("stmmac: rework DMA bus setting and introduce new
> platform AXI structure") added support for parsing all the stmmac AXI
> attributes, and added code to set most of the appropriate register bits
> with three exceptions:
>
> snps,kbbe
> snps,mb
> snps,rb
>
> [...]
Here is the summary with links:
- [net-next,1/2] net: stmmac: remove axi_kbbe, axi_mb and axi_rb members
https://git.kernel.org/netdev/net-next/c/a800398e746f
- [net-next,2/2] dt-bindings: remove unimplemented AXI snps,kbbe snps,mb and snps,rb
https://git.kernel.org/netdev/net-next/c/af0331e1ac51
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] net/dst: improve dst_ops refcounting with per-dst bit
From: Eric Dumazet @ 2026-03-27 3:51 UTC (permalink / raw)
To: xietangxin
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
netdev, eric.dumazet
In-Reply-To: <ac86fb62-d036-47af-b8ed-9d1f4ba2a835@yeah.net>
On Tue, Mar 24, 2026 at 8:42 PM xietangxin <xietangxin@yeah.net> wrote:
>
> Hi Eric,
>
> I tested your patch with my reproduction script, but the UAF still occurs
> with a warning in dst_entries_destroy() just before the crash.
>
> The reason is that for IPv6, dst_entries on the rt6_uncached_list are
> handled by rt6_uncached_list_flush_dev() during netns destruction,
> which bypasses dst_dev_put().
>
> I tested add changes like dst_dev_put() inside rt6_uncached_list_flush_dev(),
> the UAF is gone and the dst_entries_destroy warning no longer appears.
Could you share the incremental patch you added on top of mine ?
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] gve: skip error logging for retryable AdminQ commands
From: Jordan Rhee @ 2026-03-27 3:56 UTC (permalink / raw)
To: Li Xiasong
Cc: Harshitha Ramamurthy, joshwash, andrew+netdev, davem, edumazet,
kuba, pabeni, richardcochran, willemb, nktgrg, jfraker, ziweixiao,
maolson, thostet, jefrogers, alok.a.tiwari, yyd, linux-kernel,
netdev, yuehaibing, zhangchangzhong, weiyongjun1
In-Reply-To: <d5312a24-68d5-49e3-9787-9a01c8606d9a@huawei.com>
Hi Li, thank you very much for the review. The intent is only to skip
logging for *retryable* commands that return -EAGAIN. If a
non-retryable command fails, we do want to log, even if it returns
-EAGAIN.
Jordan
On Thu, Mar 26, 2026 at 7:28 PM Li Xiasong <lixiasong1@huawei.com> wrote:
>
> Hi,
>
> On 3/27/2026 6:45 AM, Harshitha Ramamurthy wrote:
> > From: Jordan Rhee <jordanrhee@google.com>
> >
> > AdminQ commands may return -EAGAIN under certain transient conditions.
> > These commands are intended to be retried by the driver, so logging
> > a formal error to the system log is misleading and creates
> > unnecessary noise.
> >
> > Modify the logging logic to skip the error message when the result
> > is -EAGAIN.
> >
> > Reviewed-by: Joshua Washington <joshwash@google.com>
> > Signed-off-by: Jordan Rhee <jordanrhee@google.com>
> > Signed-off-by: Harshitha Ramamurthy <hramamurthy@google.com>
> > ---
> > drivers/net/ethernet/google/gve/gve_adminq.c | 26 +++++++++++++++-----
> > 1 file changed, 20 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/google/gve/gve_adminq.c b/drivers/net/ethernet/google/gve/gve_adminq.c
> > index 08587bf40ed4..c7834614c5f0 100644
> > --- a/drivers/net/ethernet/google/gve/gve_adminq.c
> > +++ b/drivers/net/ethernet/google/gve/gve_adminq.c
> > @@ -416,11 +416,6 @@ static bool gve_adminq_wait_for_cmd(struct gve_priv *priv, u32 prod_cnt)
> >
> > static int gve_adminq_parse_err(struct gve_priv *priv, u32 status)
> > {
> > - if (status != GVE_ADMINQ_COMMAND_PASSED &&
> > - status != GVE_ADMINQ_COMMAND_UNSET) {
> > - dev_err(&priv->pdev->dev, "AQ command failed with status %d\n", status);
> > - priv->adminq_cmd_fail++;
> > - }
> > switch (status) {
> > case GVE_ADMINQ_COMMAND_PASSED:
> > return 0;
> > @@ -455,6 +450,16 @@ static int gve_adminq_parse_err(struct gve_priv *priv, u32 status)
> > }
> > }
> >
> > +static bool gve_adminq_is_retryable(enum gve_adminq_opcodes opcode)
> > +{
> > + switch (opcode) {
> > + case GVE_ADMINQ_REPORT_NIC_TIMESTAMP:
> > + return true;
> > + default:
> > + return false;
> > + }
> > +}
> > +
> > /* Flushes all AQ commands currently queued and waits for them to complete.
> > * If there are failures, it will return the first error.
> > */
> > @@ -482,9 +487,18 @@ static int gve_adminq_kick_and_wait(struct gve_priv *priv)
> > cmd = &priv->adminq[i & priv->adminq_mask];
> > status = be32_to_cpu(READ_ONCE(cmd->status));
> > err = gve_adminq_parse_err(priv, status);
> > - if (err)
> > + if (err) {
> > + enum gve_adminq_opcodes opcode =
> > + be32_to_cpu(READ_ONCE(cmd->opcode));
> > + priv->adminq_cmd_fail++;
> > + if (!gve_adminq_is_retryable(opcode) || err != -EAGAIN)
>
> In gve_adminq_kick_and_wait(), the condition is:
>
> if (!gve_adminq_is_retryable(opcode) || err != -EAGAIN)
> dev_err_ratelimited(...);
>
> Based on the commit log, the goal is to skip logging when the result is
> -EAGAIN for transient conditions. However, when gve_adminq_is_retryable()
> returns false (e.g., GVE_ADMINQ_COMMAND_ERROR_ABORTED), even if err is
> -EAGAIN, the condition evaluates to true and the error would still be logged.
>
> Would it be more appropriate to use && instead of || here?
>
> if (!gve_adminq_is_retryable(opcode) && err != -EAGAIN)
>
> I may be missing something, so please let me know if I've misunderstood.
>
> > + dev_err_ratelimited(&priv->pdev->dev,
> > + "AQ command %d failed with status %d\n",
> > + opcode, status);
> > +
> > // Return the first error if we failed.
> > return err;
> > + }
> > }
> >
> > return 0;
>
> Best regards,
> Li Xiasong
^ 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