* Re: [RFC Patch net-next v1 1/9] r8169: add some register definitions
From: Heiner Kallweit @ 2026-04-26 20:12 UTC (permalink / raw)
To: javen, nic_swsd, andrew+netdev, davem, edumazet, kuba, pabeni,
horms
Cc: netdev, linux-kernel
In-Reply-To: <20260420021957.1756-2-javen_xu@realsil.com.cn>
On 20.04.2026 04:19, javen wrote:
> From: Javen Xu <javen_xu@realsil.com.cn>
>
> To support rss, this patch adds some macro definitions and register
> definitions.
>
> Signed-off-by: Javen Xu <javen_xu@realsil.com.cn>
> ---
> drivers/net/ethernet/realtek/r8169_main.c | 75 +++++++++++++++++++++++
> 1 file changed, 75 insertions(+)
>
> diff --git a/drivers/net/ethernet/realtek/r8169_main.c b/drivers/net/ethernet/realtek/r8169_main.c
> index 791277e750ba..0fbec27e4a0d 100644
> --- a/drivers/net/ethernet/realtek/r8169_main.c
> +++ b/drivers/net/ethernet/realtek/r8169_main.c
> @@ -77,6 +77,23 @@
> #define R8169_RX_RING_BYTES (NUM_RX_DESC * sizeof(struct RxDesc))
> #define R8169_TX_STOP_THRS (MAX_SKB_FRAGS + 1)
> #define R8169_TX_START_THRS (2 * R8169_TX_STOP_THRS)
> +#define R8169_MAX_RX_QUEUES 8
> +#define R8169_MAX_TX_QUEUES 1
> +#define R8169_MAX_MSIX_VEC 32
> +#define R8127_MAX_TX_QUEUES 1
> +#define R8127_MAX_RX_QUEUES 8
> +#define R8127_MAX_IRQ 32
> +#define R8127_MIN_IRQ 30
Why do you need at least 30 irq vecs?
> +#define RTL8127_RSS_KEY_SIZE 40
> +#define RSS_CPU_NUM_OFFSET 16
> +#define RSS_MASK_BITS_OFFSET 8
> +#define RTL8127_MAX_INDIRECTION_TABLE_ENTRIES 128
> +#define RXS_8125B_RSS_UDP_V4 BIT(27)
This register naming is unfortunate. What stands 8125B for, and what V4?
Does V4 stand for a global version of the Realtek RSS IP block?
Then the 8125B would be redundant.
> +#define RXS_8125_RSS_IPV4_V4 BIT(28)
> +#define RXS_8125_RSS_IPV6_V4 BIT(29)
> +#define RXS_8125_RSS_TCP_V4 BIT(30)
> +#define RTL8127_RXS_RSS_L3_TYPE_MASK_V4 (RXS_8125_RSS_IPV4_V4 | RXS_8125_RSS_IPV6_V4)
> +#define RTL8127_RXS_RSS_L4_TYPE_MASK_V4 (RXS_8125_RSS_TCP_V4 | RXS_8125B_RSS_UDP_V4)
>
> #define OCP_STD_PHY_BASE 0xa400
>
> @@ -435,6 +452,8 @@ enum rtl8125_registers {
> #define INT_CFG0_CLKREQEN BIT(3)
> IntrMask_8125 = 0x38,
> IntrStatus_8125 = 0x3c,
> + IntrMask1_8125 = 0x800,
The driver has camel case for historic reasons. Camel case shouldn't
be used for new constants. Checkpatch would have warned. There are
several other places in the series where checkpatch would complain.
Therefore, use checkpatch and fix all warnings/errors.
> + IntrStatus1_8125 = 0x802,
> INT_CFG1_8125 = 0x7a,
> LEDSEL2 = 0x84,
> LEDSEL1 = 0x86,
> @@ -444,6 +463,36 @@ enum rtl8125_registers {
> RSS_CTRL_8125 = 0x4500,
> Q_NUM_CTRL_8125 = 0x4800,
> EEE_TXIDLE_TIMER_8125 = 0x6048,
> + TNPDS_Q1_LOW = 0x2100,
> + RDSAR_Q1_LOW = 0x4000,
> + IMR_V2_SET_REG_8125 = 0x0d0c,
> + IMR_V2_CLEAR_REG_8125 = 0x0d00,
> + IMR_V4_L2_CLEAR_REG_8125 = 0x0d10,
> + ISR_V2_8125 = 0x0d04,
> + ISR_V4_L2_8125 = 0x0d14,
There are registers with at least V2, V4, V6.
And like in a previous comment: Which benefit has the
8125 here (at least if the versioning is global)?
> +};
> +
> +enum rtl8127_msix_id {
> + MSIX_ID_V4_LINKCHG = 29,
> +};
> +
> +enum rtl8127_rss_register_content {
> + RSS_CTRL_TCP_IPV4_SUPP = (1 << 0),
BIT() macro can be used. And any specific reasons (except historic ones)
why you define an enum that is never used instead of defines?
> + RSS_CTRL_IPV4_SUPP = (1 << 1),
> + RSS_CTRL_TCP_IPV6_SUPP = (1 << 2),
> + RSS_CTRL_IPV6_SUPP = (1 << 3),
> + RSS_CTRL_IPV6_EXT_SUPP = (1 << 4),
> + RSS_CTRL_TCP_IPV6_EXT_SUPP = (1 << 5),
> + RSS_CTRL_UDP_IPV4_SUPP = (1 << 11),
> + RSS_CTRL_UDP_IPV6_SUPP = (1 << 12),
> + RSS_CTRL_UDP_IPV6_EXT_SUPP = (1 << 13),
> + RSS_INDIRECTION_TBL_8125_V2 = 0x4700,
> + RSS_KEY_8125 = 0x4600,
> +};
> +
> +enum rtl8127_rss_flag {
> + RTL_8125_RSS_FLAG_HASH_UDP_IPV4 = (1 << 0),
> + RTL_8125_RSS_FLAG_HASH_UDP_IPV6 = (1 << 1),
> };
>
> #define LEDSEL_MASK_8125 0x23f
> @@ -474,6 +523,10 @@ enum rtl_register_content {
> RxRUNT = (1 << 20),
> RxCRC = (1 << 19),
>
> + RxRES_RSS = (1 << 22),
> + RxRUNT_RSS = (1 << 21),
> + RxCRC_RSS = (1 << 20),
> +
> /* ChipCmdBits */
> StopReq = 0x80,
> CmdReset = 0x10,
> @@ -576,6 +629,9 @@ enum rtl_register_content {
>
> /* magic enable v2 */
> MagicPacket_v2 = (1 << 16), /* Wake up when receives a Magic Packet */
> + ISRIMR_V6_LINKCHG = (1 << 29),
> + ISRIMR_V6_TOK_Q0 = (1 << 8),
> + ISRIMR_V6_ROK_Q0 = (1 << 0),
> };
>
> enum rtl_desc_bit {
> @@ -633,6 +689,11 @@ enum rtl_rx_desc_bit {
> #define RxProtoIP (PID1 | PID0)
> #define RxProtoMask RxProtoIP
>
> + RxUDPT_v4 = (1 << 19),
> + RxTCPT_v4 = (1 << 18),
> + RxUDPF_v4 = (1 << 16), /* UDP/IP checksum failed */
> + RxTCPF_v4 = (1 << 15), /* TCP/IP checksum failed */
> +
> IPFail = (1 << 16), /* IP checksum failed */
> UDPFail = (1 << 15), /* UDP/IP checksum failed */
> TCPFail = (1 << 14), /* TCP/IP checksum failed */
> @@ -659,6 +720,11 @@ struct RxDesc {
> __le64 addr;
> };
>
> +enum features {
> + RTL_FEATURE_MSI = (1 << 1),
> + RTL_FEATURE_MSIX = (1 << 2),
> +};
> +
> struct ring_info {
> struct sk_buff *skb;
> u32 len;
> @@ -728,6 +794,13 @@ enum rtl_dash_type {
> RTL_DASH_25_BP,
> };
>
> +enum rx_desc_ring_type {
> + RX_DESC_RING_TYPE_UNKNOWN = 0,
> + RX_DESC_RING_TYPE_DEAFULT,
> + RX_DESC_RING_TYPE_RSS,
> + RX_DESC_RING_TYPE_MAX
> +};
> +
> struct rtl8169_private {
> void __iomem *mmio_addr; /* memory map physical address */
> struct pci_dev *pci_dev;
> @@ -763,6 +836,8 @@ struct rtl8169_private {
> unsigned aspm_manageable:1;
> unsigned dash_enabled:1;
> bool sfp_mode:1;
> + bool rss_support:1;
> + bool rss_enable:1;
> dma_addr_t counters_phys_addr;
> struct rtl8169_counters *counters;
> struct rtl8169_tc_offsets tc_offset;
^ permalink raw reply
* [PATCH net v2] netdevsim: zero initialize struct iphdr in dummy sk_buff
From: Nikola Z. Ivanov @ 2026-04-26 20:14 UTC (permalink / raw)
To: kuba, andrew+netdev, davem, edumazet, pabeni
Cc: netdev, linux-kernel, Nikola Z. Ivanov
Syzbot reports a KMSAN uninit-value originating from
nsim_dev_trap_skb_build, with the allocation also
being performed in the same function.
Fix this by calling skb_put_zero instead of skb_put to
guarantee zero initialization of the whole IP header.
Closes: https://syzkaller.appspot.com/bug?extid=23d7fcd204e3837866ff
Fixes: da58f90f11f5 ("netdevsim: Add devlink-trap support")
Signed-off-by: Nikola Z. Ivanov <zlatistiv@gmail.com>
---
Changes since v1:
- avoid unnecessary shuffling of struct member initialization.
https://lore.kernel.org/netdev/20260421082005.74a3efb4@kernel.org/
drivers/net/netdevsim/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/netdevsim/dev.c b/drivers/net/netdevsim/dev.c
index 1e06e781c835..f00fc2f9ebde 100644
--- a/drivers/net/netdevsim/dev.c
+++ b/drivers/net/netdevsim/dev.c
@@ -829,7 +829,7 @@ static struct sk_buff *nsim_dev_trap_skb_build(void)
skb->protocol = htons(ETH_P_IP);
skb_set_network_header(skb, skb->len);
- iph = skb_put(skb, sizeof(struct iphdr));
+ iph = skb_put_zero(skb, sizeof(struct iphdr));
iph->protocol = IPPROTO_UDP;
iph->saddr = in_aton("192.0.2.1");
iph->daddr = in_aton("198.51.100.1");
--
2.53.0
^ permalink raw reply related
* Re: [PATCH RFC net-next 0/4] net: pse-pd: decouple controller lookup from MDIO probe
From: Carlo Szelinsky @ 2026-04-26 21:25 UTC (permalink / raw)
To: kory.maincent
Cc: andrew+netdev, andrew, corey, davem, edumazet, github, hkallweit1,
kuba, linux-kernel, linux, netdev, o.rempel, pabeni
In-Reply-To: <20260424144124.131837c7@kmaincent-XPS-13-7390>
Hey,
Thanks for all the help from multiple guys :-) I am currently busy with work, but I will take some time soon!
cheers Carlo
^ permalink raw reply
* [PATCH] net: nixge: fix skb leak and missing bail on DMA mapping error
From: kernelcoredev @ 2026-04-26 21:33 UTC (permalink / raw)
To: netdev; +Cc: andrew+netdev, davem, edumazet, kuba, pabeni, kernelcoredev
When dma_mapping_error() fires during RX buffer refill in nixge_recv(),
the skb allocated by netdev_alloc_skb_ip_align() is never freed, and
execution continues writing a corrupt physical address into the hardware
descriptor ring.
Fix by freeing the skb with dev_kfree_skb() and returning early.
Fixes: 492caffa8a1a ("net: ethernet: nixge: Add support for National Instruments XGE netdev")
Signed-off-by: kernelcoredev <sonionwhat@gmail.com>
---
drivers/net/ethernet/ni/nixge.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/ni/nixge.c b/drivers/net/ethernet/ni/nixge.c
index 230d5ff99..b64e2f355 100644
--- a/drivers/net/ethernet/ni/nixge.c
+++ b/drivers/net/ethernet/ni/nixge.c
@@ -645,8 +645,9 @@ static int nixge_recv(struct net_device *ndev, int budget)
NIXGE_MAX_JUMBO_FRAME_SIZE,
DMA_FROM_DEVICE);
if (dma_mapping_error(ndev->dev.parent, cur_phys)) {
- /* FIXME: bail out and clean up */
- netdev_err(ndev, "Failed to map ...\n");
+ netdev_err(ndev, "Failed to map RX buffer\n");
+ dev_kfree_skb(new_skb);
+ return packets;
}
nixge_hw_dma_bd_set_phys(cur_p, cur_phys);
cur_p->cntrl = NIXGE_MAX_JUMBO_FRAME_SIZE;
--
2.53.0
^ permalink raw reply related
* [PATCH net-next] net: usb: r8152: add TRENDnet TUC-ET2G v2.0
From: Aleksander Jan Bajkowski @ 2026-04-26 21:49 UTC (permalink / raw)
To: andrew+netdev, davem, edumazet, kuba, pabeni, hayeswang,
hsu.chih.kai, kees, mail, linux-usb, netdev, linux-kernel
Cc: Aleksander Jan Bajkowski
The TRENDnet TUC-ET2G V2.0 is an RTL8156B based 2.5G Ethernet controller.
Add the vendor and product ID values to the driver. This makes Ethernet
work with the adapter.
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
---
drivers/net/usb/r8152.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 7337bf1b7d6a..1ace1d2398c9 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -10138,6 +10138,7 @@ static const struct usb_device_id rtl8152_table[] = {
{ USB_DEVICE(VENDOR_ID_DELL, 0xb097) },
{ USB_DEVICE(VENDOR_ID_ASUS, 0x1976) },
{ USB_DEVICE(VENDOR_ID_TRENDNET, 0xe02b) },
+ { USB_DEVICE(VENDOR_ID_TRENDNET, 0xe02c) },
{}
};
--
2.53.0
^ permalink raw reply related
* [PATCH net-next] net: phy: realtek: replace magic number with register bit macros
From: Aleksander Jan Bajkowski @ 2026-04-26 22:23 UTC (permalink / raw)
To: andrew, hkallweit1, linux, davem, edumazet, kuba, pabeni, daniel,
vladimir.oltean, michael, olek2, ih, rmk+kernel, marek.vasut,
netdev, linux-kernel
Replace magic number with register bit macros. The description of the
RTL8211B interrupt register is obtained from the datasheet.
1. RTL8211B(L) Rev. 1.5 Datasheet
Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
---
drivers/net/phy/realtek/realtek_main.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
index 79c867ef64da..9f2a0bc03728 100644
--- a/drivers/net/phy/realtek/realtek_main.c
+++ b/drivers/net/phy/realtek/realtek_main.c
@@ -40,7 +40,12 @@
RTL8201F_ISR_LINK)
#define RTL821x_INER 0x12
-#define RTL8211B_INER_INIT 0x6400
+#define RTL8211B_INER_SPEED BIT(14)
+#define RTL8211B_INER_DUPLEX BIT(13)
+#define RTL8211B_INER_LINK_STATUS BIT(10)
+#define RTL8211B_INER_INIT (RTL8211B_INER_SPEED | \
+ RTL8211B_INER_DUPLEX | \
+ RTL8211B_INER_LINK_STATUS)
#define RTL8211E_INER_LINK_STATUS BIT(10)
#define RTL8211F_INER_PME BIT(7)
#define RTL8211F_INER_LINK_STATUS BIT(4)
--
2.53.0
^ permalink raw reply related
* [REGRESSION] aquantia: Sunshine/Moonlight UDP video streaming broken since 5b4015ad833c ("net: aquantia: Remove redundant UDP length adjustment with GSO_PARTIAL")
From: Matthew Schwartz @ 2026-04-26 23:20 UTC (permalink / raw)
To: Gal Pressman, Dragos Tatulea, Jakub Kicinski
Cc: regressions, netdev, linux-kernel@vger.kernel.org
Hello,
When using a previously working setup of remote streaming from my workstation to another device via Sunshine (the host server) and Moonlight (the client app) on my home network, I no longer receive any video output on the client app after upgrading my host workstation to kernel 7.0. Reverting back to kernel 6.19 on the host restored my setup to a working state.
After bisecting, I landed on 5b4015ad833c ("net: aquantia: Remove redundant UDP length adjustment with GSO_PARTIAL") as the first bad commit. I confirmed this by moving the cable to my second on-board NIC (Intel) on the same workstation, which restored video output without any other kernel changes. My affected on-board NIC is Aquantia AQC113 [1d6a:04c0] (rev 03), atlantic driver, firmware 1.3.34, MTU 1500.
Looking into it a bit further, ethtool -K enp97s0 tx-udp-segmentation off also serves as a workaround on my Aquantia port without changing to my other ethernet port. The working Intel NIC reports tx-udp-segmentation as "off [fixed]", so traffic falls back to software UDP segmentation on there.
Please let me know if there's any additional info I can provide.
Thanks,
Matt
#regzbot introduced: 5b4015ad833c
^ permalink raw reply
* Re: [PATCH net-next v7 0/5] TLS read_sock performance scalability
From: Jakub Kicinski @ 2026-04-26 23:55 UTC (permalink / raw)
To: Chuck Lever
Cc: john.fastabend, Sabrina Dubroca, netdev, kernel-tls-handshake,
Chuck Lever, Hannes Reinecke, Alistair Francis
In-Reply-To: <4a802e09-d1af-4af3-8f02-3e2c8d25e734@app.fastmail.com>
On Sat, 25 Apr 2026 16:15:41 -0400 Chuck Lever wrote:
> On Wed, Apr 22, 2026, at 10:08 PM, Jakub Kicinski wrote:
> > On Wed, 22 Apr 2026 12:41:43 -0400 Chuck Lever wrote:
> >> I see that this series is currently not in v7.1. What is left to do?
> >
> > It's marked as Changes requested in patchwork, possibly due to
> > mis-reading of the discussion on patch 4. We process patches within
> > few days (well, we used to before the AI swarm) so if in doubt you
> > should ask sooner :S
>
> Thanks for the pointer to the netdevbpf patchworks instance. Anything
> I can do to move this series to "Awaiting upsteam" ?
Repost after net-next reopens
https://www.kernel.org/doc/html/next/process/maintainer-netdev.html
^ permalink raw reply
* [PATCH bpf-next v3 0/2] bpf,net: add missing custom syncookie statistics and add selftest
From: Jiayuan Chen @ 2026-04-27 0:09 UTC (permalink / raw)
To: bpf
Cc: Jiayuan Chen, Eric Dumazet, Neal Cardwell, Kuniyuki Iwashima,
David S. Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
David Ahern, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, Shuah Khan, netdev,
linux-kernel, linux-kselftest
v2 was reviewed on net-next; per Martin's request the series is
re-targeted at the bpf-next tree's net branch (bpf-next/net) so
both patches can land together via the BPF tree (the selftest
touches BPF selftest helpers). No code changes vs. v2 beyond the
nits below.
For context, the series accounts BPF custom syncookie validation
in the LINUX_MIB_SYNCOOKIES{RECV,FAILED} SNMP counters (with a few
related cleanups in the cookie_bpf_* config guards), and adds a
selftest that verifies the counters move as expected.
v2: https://lore.kernel.org/netdev/20260411013211.225834-1-jiayuan.chen@linux.dev/T/#m9c0ccc349fbed908e2cf34ce34ebd45b6f747b07
---
Changelog
=========
v2 -> v3:
- Retarget bpf-next/net (Martin).
- 1/2: fix typo and rationale in commit message — the removed
guard is CONFIG_BPF, not CONFIG_BPF_SYSCALL, and the reason is
that the guard is a no-op under CONFIG_NET, not a build-failure
risk (Martin).
- 2/2: keep reverse xmas tree order in create_connection()
(Kuniyuki).
- Add Reviewed-by from Kuniyuki on both patches.
Jiayuan Chen (2):
net: add missing syncookie statistics for BPF custom syncookies
selftests/bpf: verify syncookie statistics in tcp_custom_syncookie
include/net/tcp.h | 7 +++---
net/ipv4/syncookies.c | 10 ++++++---
net/ipv6/syncookies.c | 2 +-
tools/testing/selftests/bpf/network_helpers.c | 22 +++++++++++++++++++
tools/testing/selftests/bpf/network_helpers.h | 1 +
.../bpf/prog_tests/tcp_custom_syncookie.c | 20 +++++++++++++++++
6 files changed, 54 insertions(+), 8 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH bpf-next v3 1/2] net: add missing syncookie statistics for BPF custom syncookies
From: Jiayuan Chen @ 2026-04-27 0:09 UTC (permalink / raw)
To: bpf
Cc: Jiayuan Chen, Kuniyuki Iwashima, Eric Dumazet, Neal Cardwell,
David S. Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
David Ahern, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, Shuah Khan, netdev,
linux-kernel, linux-kselftest
In-Reply-To: <20260427001006.14465-1-jiayuan.chen@linux.dev>
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 guard around struct bpf_tcp_req_attrs.
Since CONFIG_BPF is always selected by CONFIG_NET the guard is a
no-op, and the struct is referenced by bpf_sk_assign_tcp_reqsk()
in net/core/filter.c which is compiled unconditionally, so its
visibility is not actually conditional on BPF being enabled.
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.
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
---
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 dfa52ceefd23b..0e3e43c7a89ce 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -599,7 +599,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;
@@ -613,7 +612,6 @@ struct bpf_tcp_req_attrs {
u8 usec_ts_ok;
u8 reserved[3];
};
-#endif
#ifdef CONFIG_SYN_COOKIES
@@ -716,13 +714,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 df479277fb801..9251d4a15c888 100644
--- a/net/ipv4/syncookies.c
+++ b/net/ipv4/syncookies.c
@@ -294,8 +294,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);
@@ -305,6 +306,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 4f6f0d751d6c5..111d7a41d9573 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 related
* [PATCH bpf-next v3 2/2] selftests/bpf: verify syncookie statistics in tcp_custom_syncookie
From: Jiayuan Chen @ 2026-04-27 0:09 UTC (permalink / raw)
To: bpf
Cc: Jiayuan Chen, Kuniyuki Iwashima, Eric Dumazet, Neal Cardwell,
David S. Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
David Ahern, Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko,
Martin KaFai Lau, Eduard Zingerman, Kumar Kartikeya Dwivedi,
Song Liu, Yonghong Song, Jiri Olsa, Shuah Khan, netdev,
linux-kernel, linux-kselftest
In-Reply-To: <20260427001006.14465-1-jiayuan.chen@linux.dev>
Add read_tcpext_snmp() helper to network_helpers which reads a
TcpExt SNMP counter via nstat, and use it in the tcp_custom_syncookie
test to verify that LINUX_MIB_SYNCOOKIESRECV is incremented and
LINUX_MIB_SYNCOOKIESFAILED stays unchanged across a successful
BPF custom syncookie validation.
The delta is captured between start_server() and accept(), which
covers the full SYN/ACK/cookie-check path for one connection.
Signed-off-by: Jiayuan Chen <jiayuan.chen@linux.dev>
Reviewed-by: Kuniyuki Iwashima <kuniyu@google.com>
---
tools/testing/selftests/bpf/network_helpers.c | 22 +++++++++++++++++++
tools/testing/selftests/bpf/network_helpers.h | 1 +
.../bpf/prog_tests/tcp_custom_syncookie.c | 20 +++++++++++++++++
3 files changed, 43 insertions(+)
diff --git a/tools/testing/selftests/bpf/network_helpers.c b/tools/testing/selftests/bpf/network_helpers.c
index b82f572641b7d..3388dd5112b6f 100644
--- a/tools/testing/selftests/bpf/network_helpers.c
+++ b/tools/testing/selftests/bpf/network_helpers.c
@@ -621,6 +621,28 @@ int get_socket_local_port(int sock_fd)
return -1;
}
+int read_tcpext_snmp(const char *name, unsigned long *val)
+{
+ char cmd[128], buf[128];
+ int ret = 0;
+ FILE *f;
+
+ snprintf(cmd, sizeof(cmd),
+ "nstat -az TcpExt%s | awk '/TcpExt/ {print $2}'", name);
+ f = popen(cmd, "r");
+ if (!f)
+ return -errno;
+
+ if (!fgets(buf, sizeof(buf), f)) {
+ ret = ferror(f) ? -errno : -ENODATA;
+ goto out;
+ }
+ *val = strtoul(buf, NULL, 10);
+out:
+ pclose(f);
+ return ret;
+}
+
int get_hw_ring_size(char *ifname, struct ethtool_ringparam *ring_param)
{
struct ifreq ifr = {0};
diff --git a/tools/testing/selftests/bpf/network_helpers.h b/tools/testing/selftests/bpf/network_helpers.h
index 79a010c88e11c..c53cd781df6e6 100644
--- a/tools/testing/selftests/bpf/network_helpers.h
+++ b/tools/testing/selftests/bpf/network_helpers.h
@@ -84,6 +84,7 @@ int make_sockaddr(int family, const char *addr_str, __u16 port,
struct sockaddr_storage *addr, socklen_t *len);
char *ping_command(int family);
int get_socket_local_port(int sock_fd);
+int read_tcpext_snmp(const char *name, unsigned long *val);
int get_hw_ring_size(char *ifname, struct ethtool_ringparam *ring_param);
int set_hw_ring_size(char *ifname, struct ethtool_ringparam *ring_param);
diff --git a/tools/testing/selftests/bpf/prog_tests/tcp_custom_syncookie.c b/tools/testing/selftests/bpf/prog_tests/tcp_custom_syncookie.c
index eaf441dc7e79b..00d5c32674fc9 100644
--- a/tools/testing/selftests/bpf/prog_tests/tcp_custom_syncookie.c
+++ b/tools/testing/selftests/bpf/prog_tests/tcp_custom_syncookie.c
@@ -91,12 +91,21 @@ static void transfer_message(int sender, int receiver)
static void create_connection(struct test_tcp_custom_syncookie_case *test_case)
{
+ unsigned long failed_before, failed_after;
+ unsigned long recv_before, recv_after;
int server, client, child;
server = start_server(test_case->family, test_case->type, test_case->addr, 0, 0);
if (!ASSERT_NEQ(server, -1, "start_server"))
return;
+ if (!ASSERT_OK(read_tcpext_snmp("SyncookiesRecv", &recv_before),
+ "read SyncookiesRecv before"))
+ goto close_server;
+ if (!ASSERT_OK(read_tcpext_snmp("SyncookiesFailed", &failed_before),
+ "read SyncookiesFailed before"))
+ goto close_server;
+
client = connect_to_fd(server, 0);
if (!ASSERT_NEQ(client, -1, "connect_to_fd"))
goto close_server;
@@ -105,9 +114,20 @@ static void create_connection(struct test_tcp_custom_syncookie_case *test_case)
if (!ASSERT_NEQ(child, -1, "accept"))
goto close_client;
+ if (!ASSERT_OK(read_tcpext_snmp("SyncookiesRecv", &recv_after),
+ "read SyncookiesRecv after"))
+ goto close_child;
+ if (!ASSERT_OK(read_tcpext_snmp("SyncookiesFailed", &failed_after),
+ "read SyncookiesFailed after"))
+ goto close_child;
+
+ ASSERT_EQ(recv_after - recv_before, 1, "SyncookiesRecv delta");
+ ASSERT_EQ(failed_after - failed_before, 0, "SyncookiesFailed delta");
+
transfer_message(client, child);
transfer_message(child, client);
+close_child:
close(child);
close_client:
close(client);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH net-deletions v2] net: remove unused ATM protocols and legacy ATM device drivers
From: patchwork-bot+netdevbpf @ 2026-04-27 0:36 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, corbet,
skhan, linux, tsbogend, maddy, mpe, npiggin, chleroy, 3chas3,
razor, idosch, jani.nikula, mchehab+huawei, tytso, herbert, geert,
ebiggers, johannes.berg, jonathan.cameron, kees, kuniyu,
fourier.thomas, andriy.shevchenko, rdunlap, akpm, linux-doc,
linux-mips, linuxppc-dev, bridge, dwmw2
In-Reply-To: <20260422041846.2035118-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Tue, 21 Apr 2026 21:18:44 -0700 you wrote:
> Remove the ATM protocol modules and PCI/SBUS ATM device drivers
> that are no longer in active use.
>
> The ATM core protocol stack, PPPoATM, BR2684, and USB DSL modem
> drivers (drivers/usb/atm/) are retained in-tree to maintain PPP
> over ATM (PPPoA) and PPPoE-over-BR2684 support for DSL connections.
>
> [...]
Here is the summary with links:
- [net-deletions,v2] net: remove unused ATM protocols and legacy ATM device drivers
https://git.kernel.org/netdev/net/c/6deb53595092
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 0/2] net: packetengines: remove obsolete PCI drivers
From: patchwork-bot+netdevbpf @ 2026-04-27 0:37 UTC (permalink / raw)
To: Mingyu Wang
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, tglx, mingo, netdev,
linux-kernel
In-Reply-To: <20260422044820.485660-1-25181214217@stu.xidian.edu.cn>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 22 Apr 2026 12:48:18 +0800 you wrote:
> As discussed with Andrew Lunn, this patch series removes the obsolete
> hamachi and yellowfin PCI drivers. Both drivers support hardware that
> is over two decades old and no longer in active use.
>
> Removing them eliminates dead code and reduces the overall maintenance
> burden on the netdev subsystem.
>
> [...]
Here is the summary with links:
- [1/2] net: packetengines: remove obsolete hamachi driver
https://git.kernel.org/netdev/net/c/4cf42f9c3e36
- [2/2] net: packetengines: remove obsolete yellowfin driver and vendor dir
https://git.kernel.org/netdev/net/c/aec3202247b4
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-deletions] net: remove ISDN subsystem and Bluetooth CMTP
From: patchwork-bot+netdevbpf @ 2026-04-27 0:37 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, corbet,
skhan, marcel, luiz.dentz, mchehab+huawei, jani.nikula, gregkh,
demarchi, rdunlap, justonli, ivecera, jonathan.cameron, kees,
marco.crivellari, ferr.lambarginio, nihaal, mingo, tglx, linmq006,
linux-doc, linux-bluetooth
In-Reply-To: <20260421022108.1299678-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Mon, 20 Apr 2026 19:21:07 -0700 you wrote:
> Remove the ISDN (mISDN, CAPI) subsystem and Bluetooth CMTP protocol
> from the kernel tree.
>
> ISDN is a pretty old technology and it's unclear whether anyone still
> uses it. I went over the last few years of git history and all the
> commits are either tree-wide conversions or syzbot/static analyzer
> fixes.
>
> [...]
Here is the summary with links:
- [net-deletions] net: remove ISDN subsystem and Bluetooth CMTP
https://git.kernel.org/netdev/net/c/4f10f1dfb235
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [bug report] Potential refcounting
From: Ginger @ 2026-04-27 2:07 UTC (permalink / raw)
To: tariqt; +Cc: netdev, linux-rdma, linux-kernel
Dear Linux kernel maintainers,
My research-based static analyzer found a potential
refcounting/atomicity bug within the
'drivers/net/ethernet/mellanox/mlx4' subsystem, more specifically, in
'drivers/net/ethernet/mellanox/mlx4/cq.c'.
Kernel version: long-term kernel v6.18.9
Potential concurrent triggering executions:
T0:
mlx4_cq_tasklet_cb
--> if (refcount_dec_and_test(&mcq->refcount))
--> complete(&mcq->free)
T1:
mlx4_cq_completion
--> cq->comp(cq);
--> mlx4_add_cq_to_tasklet(struct mlx4_cq *cq)
--> spin_lock_irqsave(&tasklet_ctx->lock, flags);
--> refcount_inc(&cq->refcount);
--> spin_unlock_irqrestore(&tasklet_ctx->lock, flags);
In T1, the refcounting increment on 'cq->refcount)', although within
the protection range of the 'tasklet_ctx->locl', is not synchronized
against T0 because 'refcount_inc()' does not check whether the
refcount has reached zero in T0. This case is potentially problematic
because T0 decrements he 'mcq->refcount' and can enable the
'mlx4_cq_free()' to proceed.
Thank you for your time and consideration.
Best regards,
Ginger
^ permalink raw reply
* Re: [GIT PULL] Networking deletions for 7.1
From: Andrew Lunn @ 2026-04-27 2:12 UTC (permalink / raw)
To: Daniel Palmer
Cc: Jakub Kicinski, torvalds, davem, netdev, linux-kernel, pabeni
In-Reply-To: <CAFr9PXnNVL4mUEu19jMu2sPkOucGK7Q32iB-7FY8eUpKZY_XJA@mail.gmail.com>
> If this does get merged and someone wants to put one of them back will
> it be as simple as sending a revert?
Yes. Ideally with a patch adding an entry to MAINTAINERS for who ever
is volunteering to maintain it.
With drivers this old, my _guess_ is, those people still using them
are not your typical users, but enthusiasts with the skills needed to
do patch triage. Decide if AI/bot driver bug reports are worth fixing,
and patches generated by newbies are helpful/harmful, etc.
Andrew
^ permalink raw reply
* Re: [PATCH net-next] net: bcmasp: handle EPROBE_DEFER for MAC retrieval
From: Andrew Lunn @ 2026-04-27 2:19 UTC (permalink / raw)
To: Rosen Penev
Cc: netdev, Justin Chen, Florian Fainelli, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
open list:BROADCOM ASP 2.0 ETHERNET DRIVER, open list
In-Reply-To: <20260425013734.436147-1-rosenp@gmail.com>
On Fri, Apr 24, 2026 at 06:37:34PM -0700, Rosen Penev wrote:
> of_get_ethdev_address can return EPROBE_DEFER when using nvmem. To
> handle this, encode the error with ERR_PTR for minimal changes. Adjust
> the only place using bcmasp_interface_create.
>
> Signed-off-by: Rosen Penev <rosenp@gmail.com>
> ---
> drivers/net/ethernet/broadcom/asp2/bcmasp.c | 4 ++--
> drivers/net/ethernet/broadcom/asp2/bcmasp_intf.c | 6 ++++--
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/broadcom/asp2/bcmasp.c b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
> index 972474893a6b..31a9560c4aee 100644
> --- a/drivers/net/ethernet/broadcom/asp2/bcmasp.c
> +++ b/drivers/net/ethernet/broadcom/asp2/bcmasp.c
> @@ -1333,10 +1333,10 @@ static int bcmasp_probe(struct platform_device *pdev)
> i = 0;
> for_each_available_child_of_node_scoped(ports_node, intf_node) {
> intf = bcmasp_interface_create(priv, intf_node, i);
> - if (!intf) {
> + if (IS_ERR(intf)) {
> dev_err(dev, "Cannot create eth interface %d\n", i);
Idealy, this should be changed to dev_err_probe(), so the
EPROBE_DEFFER case does not spam the log.
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH] net: ethernet: rnpgbe: mark nonfunctional incomplete driver as BROKEN
From: Yibo Dong @ 2026-04-27 2:19 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: netdev, stable, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vadim Fedorenko, MD Danish Anwar
In-Reply-To: <20260425041816.19070-1-enelsonmoore@gmail.com>
On Fri, Apr 24, 2026 at 09:18:15PM -0700, Ethan Nelson-Moore wrote:
> The rnpgbe driver as currently shipped in the kernel is incomplete and
> has no useful functionality. It will bind to a PCI device and create a
> network device, but that device does not function (its .ndo_start_xmit
> callback, rnpgbe_xmit_frame, just drops all packets). This situation
> means that users could enable this driver and have it load and attach
> to their device but not transfer any data. To remove the potential for
> user confusion, mark the driver as broken until it is completed and
> explain why this was done.
>
Thank you for the patch.
The TX/RX functionality patches for this driver are still under submission,
and I agree to mark the driver as BROKEN for now. I will revise this part
and remove the BROKEN dependency in the subsequent patches that add full
TX/RX functionality.
> Fixes: ee61c10cd482 ("net: rnpgbe: Add build support for rnpgbe")
> Cc: stable@vger.kernel.org # 7.0+
> Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com>
> ---
> drivers/net/ethernet/mucse/Kconfig | 9 +++++++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/mucse/Kconfig b/drivers/net/ethernet/mucse/Kconfig
> index 0b3e853d625f..c37a90a6c808 100644
> --- a/drivers/net/ethernet/mucse/Kconfig
> +++ b/drivers/net/ethernet/mucse/Kconfig
> @@ -3,9 +3,12 @@
> # Mucse network device configuration
> #
>
> +# This section depends on BROKEN because its only child item also does;
> +# see the explanation below.
> config NET_VENDOR_MUCSE
> bool "Mucse devices"
> default y
> + depends on BROKEN
> help
> If you have a network (Ethernet) card from Mucse(R), say Y.
>
> @@ -16,12 +19,14 @@ config NET_VENDOR_MUCSE
>
> if NET_VENDOR_MUCSE
>
> +# This driver is marked as broken because it is incomplete; this avoids users
> +# enabling it and expecting it to work.
> config MGBE
> tristate "Mucse(R) 1GbE PCI Express adapters support"
> - depends on PCI
> + depends on PCI && BROKEN
> help
> This driver supports Mucse(R) 1GbE PCI Express family of
> - adapters.
> + adapters. It is incomplete and currently has no useful functionality.
>
> More specific information on configuring the driver is in
> <file:Documentation/networking/device_drivers/ethernet/mucse/rnpgbe.rst>.
> --
> 2.43.0
>
>
^ permalink raw reply
* Re: [BUG] KASAN: slab-use-after-free Write in sk_skb_reason_drop
From: Eulgyu Kim @ 2026-04-27 2:21 UTC (permalink / raw)
To: edumazet, jiayuan.chen, pabeni
Cc: davem, kuba, horms, netdev, linux-kernel, byoungyoung, jjy600901
In-Reply-To: <9992caa6-ec37-4727-ae5d-80d0b5b596c0@linux.dev>
>
> The fix could be this:
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index b183189f1853..6a0bbd4def76 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -289,8 +289,12 @@ static void tun_napi_disable(struct tun_file *tfile)
>
> static void tun_napi_del(struct tun_file *tfile)
> {
> - if (tfile->napi_enabled)
> - netif_napi_del(&tfile->napi);
> + if (!tfile->napi_enabled)
> + return;
> +
> + mutex_lock(&tfile->napi_mutex);
> + netif_napi_del(&tfile->napi);
> + mutex_unlock(&tfile->napi_mutex);
> }
>
> static bool tun_napi_frags_enabled(const struct tun_file *tfile)
> @@ -1783,6 +1787,12 @@ static ssize_t tun_get_user(struct tun_struct
> *tun, struct tun_file *tfile,
>
> if (frags) {
> mutex_lock(&tfile->napi_mutex);
> + if (unlikely(tfile->detached ||
> + rcu_access_pointer(tfile->tun) != tun)) {
> + err = -EBUSY;
> + mutex_unlock(&tfile->napi_mutex);
> + goto out;
> + }
> skb = tun_napi_alloc_frags(tfile, copylen, from);
> /* tun_napi_alloc_frags() enforces a layout for
> the skb.
> * If zerocopy is enabled, then this layout will be
> @@ -1981,6 +1991,7 @@ static ssize_t tun_get_user(struct tun_struct
> *tun, struct tun_file *tfile,
> mutex_unlock(&tfile->napi_mutex);
> }
>
> +out:
> return err ?: total_len;
> }
>
Hello,
We have tested the proposed patch, and our reproducer did not trigger any issue.
Thanks!
Best Regards,
Eulgyu Kim
^ permalink raw reply
* Re: [RFC Patch net-next v1 1/9] r8169: add some register definitions
From: Andrew Lunn @ 2026-04-27 2:30 UTC (permalink / raw)
To: Heiner Kallweit
Cc: javen, nic_swsd, andrew+netdev, davem, edumazet, kuba, pabeni,
horms, netdev, linux-kernel
In-Reply-To: <59c06e34-2782-438e-bfd7-a8d475f34f95@gmail.com>
> > +#define RXS_8125B_RSS_UDP_V4 BIT(27)
>
> This register naming is unfortunate. What stands 8125B for, and what V4?
> Does V4 stand for a global version of the Realtek RSS IP block?
> Then the 8125B would be redundant.
Maybe UDP carried inside an IPv4 package?
> > + RSS_CTRL_IPV4_SUPP = (1 << 1),
> > + RSS_CTRL_TCP_IPV6_SUPP = (1 << 2),
> > + RSS_CTRL_IPV6_SUPP = (1 << 3),
> > + RSS_CTRL_IPV6_EXT_SUPP = (1 << 4),
> > + RSS_CTRL_TCP_IPV6_EXT_SUPP = (1 << 5),
> > + RSS_CTRL_UDP_IPV4_SUPP = (1 << 11),
> > + RSS_CTRL_UDP_IPV6_SUPP = (1 << 12),
> > + RSS_CTRL_UDP_IPV6_EXT_SUPP = (1 << 13),
> > + RSS_INDIRECTION_TBL_8125_V2 = 0x4700,
> > + RSS_KEY_8125 = 0x4600,
> > + RxUDPT_v4 = (1 << 19),
> > + RxTCPT_v4 = (1 << 18),
> > + RxUDPF_v4 = (1 << 16), /* UDP/IP checksum failed */
> > + RxTCPF_v4 = (1 << 15), /* TCP/IP checksum failed */
I agree that in general there needs to be better naming. These could
again be referring to IPv4? But the v2 references are clearly not an
IP version.
Andrew
^ permalink raw reply
* Re: [PATCH DRAFT] net: cirrus: ep93xx: fix probe error unwind
From: Andrew Lunn @ 2026-04-27 2:35 UTC (permalink / raw)
To: 박명훈
Cc: Hartley Sweeten, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Ijae Kim, netdev, linux-kernel
In-Reply-To: <20260426141010.19049-1-pakmyeonghun@bagmyeonghun-ui-MacBookPro.local>
On Sun, Apr 26, 2026 at 11:10:06PM +0900, 박명훈 wrote:
> From: Myeonghun Pak <mhun512@gmail.com>
>
> ep93xx_eth_probe() uses ep93xx_eth_remove() as common error unwind
> after setting driver data. When register_netdev() fails, this calls
> unregister_netdev() for a net_device that was never registered. The
> net core treats that as a driver bug and emits WARN_ON(1).
How did you trigger the failure of register_netdev()?
Andrew
^ permalink raw reply
* Re: [PATCH] net: nixge: fix skb leak and missing bail on DMA mapping error
From: Andrew Lunn @ 2026-04-27 2:42 UTC (permalink / raw)
To: kernelcoredev; +Cc: netdev, andrew+netdev, davem, edumazet, kuba, pabeni
In-Reply-To: <20260426213316.6164-1-sonionwhat@gmail.com>
On Sun, Apr 26, 2026 at 05:33:16PM -0400, kernelcoredev wrote:
> When dma_mapping_error() fires during RX buffer refill in nixge_recv(),
> the skb allocated by netdev_alloc_skb_ip_align() is never freed, and
> execution continues writing a corrupt physical address into the hardware
> descriptor ring.
>
> Fix by freeing the skb with dev_kfree_skb() and returning early.
>
> Fixes: 492caffa8a1a ("net: ethernet: nixge: Add support for National Instruments XGE netdev")
>
> Signed-off-by: kernelcoredev <sonionwhat@gmail.com>
Please read
https://docs.kernel.org/process/submitting-patches.html
In particular:
https://docs.kernel.org/process/submitting-patches.html#developer-s-certificate-of-origin-1-1
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next] net: usb: r8152: add TRENDnet TUC-ET2G v2.0
From: Andrew Lunn @ 2026-04-27 2:43 UTC (permalink / raw)
To: Aleksander Jan Bajkowski
Cc: andrew+netdev, davem, edumazet, kuba, pabeni, hayeswang,
hsu.chih.kai, kees, mail, linux-usb, netdev, linux-kernel
In-Reply-To: <20260426214909.3426105-1-olek2@wp.pl>
On Sun, Apr 26, 2026 at 11:49:00PM +0200, Aleksander Jan Bajkowski wrote:
> The TRENDnet TUC-ET2G V2.0 is an RTL8156B based 2.5G Ethernet controller.
>
> Add the vendor and product ID values to the driver. This makes Ethernet
> work with the adapter.
>
> Signed-off-by: Aleksander Jan Bajkowski <olek2@wp.pl>
I don't think i've seen an email yet that netdev is open after the
merge window.
Please post again when it does, and include Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* [RFC PATCH] ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV
From: Vincent Chen @ 2026-04-27 3:11 UTC (permalink / raw)
To: anthony.l.nguyen, przemyslaw.kitszel, andrew+netdev, davem,
edumazet, kuba, pabeni
Cc: intel-wired-lan, netdev, vincent.chen
Currently ice_eswitch_attach_vf() is called unconditionally in
ice_start_vfs() and ice_reset_all_vfs(), which causes VF creation
to fail when CONFIG_ICE_SWITCHDEV is not defined or switchdev mode
is not enabled at runtime.
Fix this by adding switchdev mode checks at the call sites before
calling ice_eswitch_attach_vf(), consistent with how
ice_eswitch_attach_sf() is already handled in ice_devlink_port_new().
Also remove the redundant check inside ice_eswitch_attach_vf() itself.
This is similar to commit aacca7a83b97 ("ice: allow creating VFs for
!CONFIG_NET_SWITCHDEV") which fixed the same issue for the previous
ice_eswitch_configure() API.
Signed-off-by: Vincent Chen <vincent.chen@sifive.com>
---
drivers/net/ethernet/intel/ice/ice_eswitch.c | 3 ---
drivers/net/ethernet/intel/ice/ice_sriov.c | 14 ++++++++------
drivers/net/ethernet/intel/ice/ice_vf_lib.c | 3 ++-
3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_eswitch.c b/drivers/net/ethernet/intel/ice/ice_eswitch.c
index 2e4f0969035f..c709decb26d5 100644
--- a/drivers/net/ethernet/intel/ice/ice_eswitch.c
+++ b/drivers/net/ethernet/intel/ice/ice_eswitch.c
@@ -512,9 +512,6 @@ int ice_eswitch_attach_vf(struct ice_pf *pf, struct ice_vf *vf)
struct ice_repr *repr;
int err;
- if (!ice_is_eswitch_mode_switchdev(pf))
- return 0;
-
repr = ice_repr_create_vf(vf);
if (IS_ERR(repr))
return PTR_ERR(repr);
diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
index 843e82fd3bf9..6a0b724e46f9 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.c
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
@@ -484,12 +484,14 @@ static int ice_start_vfs(struct ice_pf *pf)
goto teardown;
}
- retval = ice_eswitch_attach_vf(pf, vf);
- if (retval) {
- dev_err(ice_pf_to_dev(pf), "Failed to attach VF %d to eswitch, error %d",
- vf->vf_id, retval);
- ice_vf_vsi_release(vf);
- goto teardown;
+ if (ice_is_eswitch_mode_switchdev(pf)) {
+ retval = ice_eswitch_attach_vf(pf, vf);
+ if (retval) {
+ dev_err(ice_pf_to_dev(pf), "Failed to attach VF %d to eswitch, error %d",
+ vf->vf_id, retval);
+ ice_vf_vsi_release(vf);
+ goto teardown;
+ }
}
set_bit(ICE_VF_STATE_INIT, vf->vf_states);
diff --git a/drivers/net/ethernet/intel/ice/ice_vf_lib.c b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
index de9e81ccee66..71595410174c 100644
--- a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
@@ -807,7 +807,8 @@ void ice_reset_all_vfs(struct ice_pf *pf)
ice_vf_rebuild_vsi(vf);
ice_vf_post_vsi_rebuild(vf);
- ice_eswitch_attach_vf(pf, vf);
+ if (ice_is_eswitch_mode_switchdev(pf))
+ ice_eswitch_attach_vf(pf, vf);
mutex_unlock(&vf->cfg_lock);
}
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v3 net 06/11] octeontx2-af: npc: cn20k: Clear MCAM entries by index and key width
From: Ratheesh Kannoth @ 2026-04-27 3:44 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: sgoutham, davem, edumazet, kuba, pabeni, andrew+netdev,
Suman Ghosh
In-Reply-To: <20260423104317.2707923-7-rkannoth@marvell.com>
On 2026-04-23 at 16:13:12, Ratheesh Kannoth (rkannoth@marvell.com) wrote:
> Replace the old four-argument CN20K MCAM clear with a per-bank static
> helper and npc_cn20k_clear_mcam_entry() that takes a logical MCAM index,
https://sashiko.dev/#/patchset/20260423104317.2707923-1-rkannoth%40marvell.com
> @@ -755,9 +762,15 @@ void rvu_npc_install_promisc_entry(struct rvu *rvu, u16 pcifunc,
>
> /* If the corresponding PF's ucast action is RSS,
> * use the same action for promisc also
> + * Please note that for lbk(s) "index" and "ucast_idx"
> + * will be same.
> */
> - ucast_idx = npc_get_nixlf_mcam_index(mcam, pcifunc,
> - nixlf, NIXLF_UCAST_ENTRY);
> + if (is_lbk_vf(rvu, pcifunc))
> + ucast_idx = index;
> + else
> + ucast_idx = npc_get_nixlf_mcam_index(mcam, pcifunc,
> + nixlf, NIXLF_UCAST_ENTRY);
> +
Should this LBK VF handling also be applied to rvu_npc_install_allmulti_entry()
and rvu_npc_update_flowkey_alg_idx()?
It looks like rvu_npc_install_allmulti_entry() tries to skip LBK VFs but uses
an impossible condition:
if (is_lbk_vf(...) && is_sdp_vf(...))
Since a VF cannot be both simultaneously, LBK VFs proceed and call
npc_get_nixlf_mcam_index() for NIXLF_ALLMULTI_ENTRY and NIXLF_UCAST_ENTRY.
For LBK VFs, npc_cn20k_dft_rules_idx_get() only populates the promisc pointer
and returns 0, leaving the stack variables for mcast and ucast uninitialized.
These uninitialized values might then be used to read and write hardware
rules via rvu_mbox_handler_npc_install_flow(), potentially corrupting MCAM
rules.
Agree, but this bug is introduced by a different commit. But the change
"Patch 6: [PATCH v3 net 06/11] octeontx2-af: npc: cn20k: Clear MCAM entries by index and key width"
is a bug fix and is for another issue. So dont want to club it with this and will be addressed
in a followup patch; that will be posted once this patch series is merged.
Similarly, rvu_npc_update_flowkey_alg_idx() retrieves NIXLF_UCAST_ENTRY
without checking for LBK VFs, which might lead to the same uninitialized read.
Even if later commits in this series initialize these variables to zero, could
that just cause deterministic corruption of MCAM index 0 instead of random
memory corruption, unless LBK VFs are properly handled or skipped in these
functions as well?
Agree, but this bug is introduced by a different commit. But the change
"Patch 6: [PATCH v3 net 06/11] octeontx2-af: npc: cn20k: Clear MCAM entries by index and key width"
is a bug fix and is for another issue. So dont want to club it with this and will be addressed
in a followup patch; that will be posted once this patch series is merged.
^ 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