* Re: [PATCH net v2] ipvs: fix NULL deref in ip_vs_add_service error path
From: Simon Horman @ 2026-04-03 15:09 UTC (permalink / raw)
To: Weiming Shi
Cc: Julian Anastasov, Pablo Neira Ayuso, Florian Westphal,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Phil Sutter, netdev, lvs-devel, netfilter-devel, coreteam,
Xiang Mei
In-Reply-To: <20260401075800.3344266-2-bestswngs@gmail.com>
On Wed, Apr 01, 2026 at 03:58:01PM +0800, Weiming Shi wrote:
> When ip_vs_bind_scheduler() succeeds in ip_vs_add_service(), the local
> variable sched is set to NULL. If ip_vs_start_estimator() subsequently
> fails, the out_err cleanup calls ip_vs_unbind_scheduler(svc, sched)
> with sched == NULL. ip_vs_unbind_scheduler() passes the cur_sched NULL
> check (because svc->scheduler was set by the successful bind) but then
> dereferences the NULL sched parameter at sched->done_service, causing a
> kernel panic at offset 0x30 from NULL.
>
> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI
> KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
> RIP: 0010:ip_vs_unbind_scheduler (net/netfilter/ipvs/ip_vs_sched.c:69)
> Call Trace:
> <TASK>
> ip_vs_add_service.isra.0 (net/netfilter/ipvs/ip_vs_ctl.c:1500)
> do_ip_vs_set_ctl (net/netfilter/ipvs/ip_vs_ctl.c:2809)
> nf_setsockopt (net/netfilter/nf_sockopt.c:102)
> ip_setsockopt (net/ipv4/ip_sockglue.c:1427)
> raw_setsockopt (net/ipv4/raw.c:850)
> do_sock_setsockopt (net/socket.c:2322)
> __sys_setsockopt (net/socket.c:2339)
> __x64_sys_setsockopt (net/socket.c:2350)
> do_syscall_64 (arch/x86/entry/syscall_64.c:94)
> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
> </TASK>
>
> Fix by simply not clearing the local sched variable after a successful
> bind. ip_vs_unbind_scheduler() already detects whether a scheduler is
> installed via svc->scheduler, and keeping sched non-NULL ensures the
> error path passes the correct pointer to both ip_vs_unbind_scheduler()
> and ip_vs_scheduler_put().
>
> Fixes: 05f00505a89a ("ipvs: fix crash if scheduler is changed")
> Reported-by: Xiang Mei <xmei5@asu.edu>
> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
Acked-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] net: rnpgbe: Add TX/RX and link status support
From: Jakub Kicinski @ 2026-04-03 15:12 UTC (permalink / raw)
To: Dong Yibo
Cc: andrew+netdev, davem, edumazet, pabeni, danishanwar,
vadim.fedorenko, horms, linux-kernel, netdev
In-Reply-To: <20260403025713.527841-1-dong100@mucse.com>
On Fri, 3 Apr 2026 10:57:09 +0800 Dong Yibo wrote:
> This patch series adds the packet transmission, reception, and link status
> management features to the RNPGBE driver, building upon the previously
> introduced mailbox communication and basic driver infrastructure.
drivers/net/ethernet/mucse/rnpgbe/rnpgbe.h:183:19-23: WARNING use flexible-array member instead (https://www.kernel.org/doc/html/latest/process/deprecated.html#zero-length-and-one-element-arrays)
nit: checkpatch complains about a few lines over 80 chars too
--
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration
From: Andrew Lunn @ 2026-04-03 15:16 UTC (permalink / raw)
To: Carlo Szelinsky
Cc: Kory Maincent, Oleksij Rempel, Andrew Lunn, Heiner Kallweit,
Russell King, Jakub Kicinski, David S . Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, netdev, linux-kernel
In-Reply-To: <20260403133111.3304497-1-github@szelinsky.de>
On Fri, Apr 03, 2026 at 03:31:11PM +0200, Carlo Szelinsky wrote:
> Hi Andrew,
>
> Thx for helping me!
> I thought of keeping the eager path so we still catch broken DT bindings
> early at boot instead of silently failing later on first ethtool access.
> But you're right, dropping it would simplify things quite a bit. Do you
> think that trade-off is worth it? I will follow your lead.
I suppose, the real question is, are we fixing the correct thing?
As a general principal in Linux, you don't register a device with the
core until it has all the resources it needs. This is what
EPROBE_DEFFER is about. If it is not registered with the core, the
uAPI is not available, making user space simpler.
As i understand the problem, by deferring the probe, the regulator
gets turned off, cutting the power?
So is the real problem with the regulator code? Do we need a way to
indicate a regulator should not be turned off if it is unused?
Or can we change when the regulator code turns off unused regulators?
I don't remember all the details for deferred probing, but i thought
the driver core had a timer and would keep running the deferred probes
until that timer expires. When does the regulator code turn off unused
regulators relative to this timer?
Andrew
^ permalink raw reply
* Re: [PATCH V4 1/3] net: stmmac: Fix PTP ref clock for Tegra234
From: Simon Horman @ 2026-04-03 15:16 UTC (permalink / raw)
To: Jon Hunter
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Thierry Reding, netdev, devicetree, linux-tegra
In-Reply-To: <20260401102941.17466-2-jonathanh@nvidia.com>
On Wed, Apr 01, 2026 at 11:29:39AM +0100, Jon Hunter wrote:
> Since commit 030ce919e114 ("net: stmmac: make sure that ptp_rate is not
> 0 before configuring timestamping") was added the following error is
> observed on Tegra234:
>
> ERR KERN tegra-mgbe 6800000.ethernet eth0: Invalid PTP clock rate
> WARNING KERN tegra-mgbe 6800000.ethernet eth0: PTP init failed
>
> It turns out that the Tegra234 device-tree binding defines the PTP ref
> clock name as 'ptp-ref' and not 'ptp_ref' and the above commit now
> exposes this and that the PTP clock is not configured correctly.
>
> In order to update device-tree to use the correct 'ptp_ref' name, update
> the Tegra MGBE driver to use 'ptp_ref' by default and fallback to using
> 'ptp-ref' if this clock name is present.
>
> Fixes: d8ca113724e7 ("net: stmmac: tegra: Add MGBE support")
> Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
The nit below notwithstanding this looks good to me.
Reviewed-by: Simon Horman <horms@kernel.org>
> ---
> .../net/ethernet/stmicro/stmmac/dwmac-tegra.c | 20 +++++++++++++++++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c
> index b4b39e6a169e..3af2f001fada 100644
> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c
> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-tegra.c
...
> @@ -216,6 +216,7 @@ static int tegra_mgbe_probe(struct platform_device *pdev)
> struct plat_stmmacenet_data *plat;
> struct stmmac_resources res;
> struct tegra_mgbe *mgbe;
> + bool use_legacy_ptp = false;
> int irq, err, i;
> u32 value;
>
nit: As this is Networking code, please retain reverse xmas tree order --
longest line to shortest -- for local variable declarations.
...
^ permalink raw reply
* Re: [PATCH v9 01/10] x86/bhi: x86/vmscape: Move LFENCE out of clear_bhb_loop()
From: Borislav Petkov @ 2026-04-03 15:16 UTC (permalink / raw)
To: Pawan Gupta
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Sean Christopherson, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <20260402-vmscape-bhb-v9-1-94d16bc29774@linux.intel.com>
On Thu, Apr 02, 2026 at 05:30:47PM -0700, Pawan Gupta wrote:
> Currently, the BHB clearing sequence is followed by an LFENCE to prevent
> transient execution of subsequent indirect branches prematurely. However,
> the LFENCE barrier could be unnecessary in certain cases. For example, when
> the kernel is using the BHI_DIS_S mitigation, and BHB clearing is only
> needed for userspace. In such cases, the LFENCE is redundant because ring
> transitions would provide the necessary serialization.
>
> Below is a quick recap of BHI mitigation options:
>
> On Alder Lake and newer
>
> BHI_DIS_S: Hardware control to mitigate BHI in ring0. This has low
> performance overhead.
>
> Long loop: Alternatively, a longer version of the BHB clearing sequence
> can be used to mitigate BHI. It can also be used to mitigate the BHI
> variant of VMSCAPE. This is not yet implemented in Linux.
>
> On older CPUs
>
> Short loop: Clears BHB at kernel entry and VMexit. The "Long loop" is
> effective on older CPUs as well, but should be avoided because of
> unnecessary overhead.
>
> On Alder Lake and newer CPUs, eIBRS isolates the indirect targets between
> guest and host. But when affected by the BHI variant of VMSCAPE, a guest's
> branch history may still influence indirect branches in userspace. This
> also means the big hammer IBPB could be replaced with a cheaper option that
> clears the BHB at exit-to-userspace after a VMexit.
>
> In preparation for adding the support for the BHB sequence (without LFENCE)
> on newer CPUs, move the LFENCE to the caller side after clear_bhb_loop() is
> executed. Allow callers to decide whether they need the LFENCE or not. This
> adds a few extra bytes to the call sites, but it obviates the need for
> multiple variants of clear_bhb_loop().
>
> Suggested-by: Dave Hansen <dave.hansen@linux.intel.com>
> Tested-by: Jon Kohler <jon@nutanix.com>
> Reviewed-by: Nikolay Borisov <nik.borisov@suse.com>
> Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> ---
> arch/x86/entry/entry_64.S | 5 ++++-
> arch/x86/include/asm/nospec-branch.h | 4 ++--
> arch/x86/net/bpf_jit_comp.c | 2 ++
> 3 files changed, 8 insertions(+), 3 deletions(-)
Acked-by: Borislav Petkov (AMD) <bp@alien8.de>
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
^ permalink raw reply
* Re: [PATCH net-next] psp: add missing device stats to get-stats reply attributes
From: Willem de Bruijn @ 2026-04-03 15:18 UTC (permalink / raw)
To: Daniel Zahka, Jakub Kicinski, Willem de Bruijn, David S. Miller,
Eric Dumazet, Paolo Abeni, Simon Horman, Donald Hunter
Cc: netdev, linux-kernel
In-Reply-To: <20260403-psp-yaml-fix-v1-1-dacee0663903@gmail.com>
Daniel Zahka wrote:
> Commit f05d26198cf2 ("psp: add stats from psp spec to driver facing
> api") added device statistics (rx-packets, rx-bytes, rx-auth-fail,
> rx-error, rx-bad, tx-packets, tx-bytes, tx-error) to the stats
> attribute-set but did not add them to the get-stats operation reply
> attributes. The kernel reports these attributes in the reply, so
> list them in the spec to match.
>
> Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> Signed-off-by: Daniel Zahka <daniel.zahka@gmail.com>
Acked-by: Willem de Bruijn <willemb@google.com>
^ permalink raw reply
* Re: [PATCH net-next v2 3/4] net: dsa: yt921x: Add port police support
From: David Yang @ 2026-04-03 15:18 UTC (permalink / raw)
To: Andrew Lunn
Cc: netdev, Vladimir Oltean, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-kernel
In-Reply-To: <308c4474-3da3-41bf-af29-3a400232e029@lunn.ch>
On Fri, Apr 3, 2026 at 10:19 PM Andrew Lunn <andrew@lunn.ch> wrote:
>
> > Does it unnecessarily depend on __int128? Otherwise it's good.
>
> Ah, it seems to be a 64 bit architecture only thing.
>
> Shame, because it would make this code easier to understand.
>
> For these u96 values, the masks i looked at would fit into a u64. Are
> there any fields which cross from bits < 64 to > 64? Could you
> represent it as a u64+u32?
>
> Andrew
EBS crosses word #0 and #1 and CBS crosses word #1 and #2, and I
didn't find any boundary patterns among other u96 registers.
But maybe I could drop those multi-word register helpers and use
manual updates, since I have to use unaligned modifications anyway.
^ permalink raw reply
* Re: [net-next 2/3] selftests/net: Test PACKET_STATISTICS drops
From: Willem de Bruijn @ 2026-04-03 15:26 UTC (permalink / raw)
To: Joe Damato, netdev, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Shuah Khan
Cc: andrew+netdev, linux-kernel, willemb, Joe Damato, linux-kselftest
In-Reply-To: <20260402232203.2004496-3-joe@dama.to>
Joe Damato wrote:
> Extend psock_snd to test drops by setting a tiny receive buffer and
> sending a large burst of packets.
>
> Signed-off-by: Joe Damato <joe@dama.to>
> ---
> tools/testing/selftests/net/psock_snd.c | 52 ++++++++++++++++++++----
> tools/testing/selftests/net/psock_snd.sh | 5 +++
> 2 files changed, 48 insertions(+), 9 deletions(-)
>
> diff --git a/tools/testing/selftests/net/psock_snd.c b/tools/testing/selftests/net/psock_snd.c
> index 5be481a3d2bd..7bbce274b9f0 100644
> --- a/tools/testing/selftests/net/psock_snd.c
> +++ b/tools/testing/selftests/net/psock_snd.c
> @@ -39,6 +39,7 @@ static bool cfg_use_gso;
> static bool cfg_use_qdisc_bypass;
> static bool cfg_use_vlan;
> static bool cfg_use_vnet;
> +static bool cfg_drop;
>
> static char *cfg_ifname = "lo";
> static int cfg_mtu = 1500;
> @@ -49,6 +50,8 @@ static uint16_t cfg_port = 8000;
> /* test sending up to max mtu + 1 */
> #define TEST_SZ (sizeof(struct virtio_net_hdr) + ETH_HLEN + ETH_MAX_MTU + 1)
>
> +#define BURST_CNT (1000)
> +
> static char tbuf[TEST_SZ], rbuf[TEST_SZ];
>
> static unsigned long add_csum_hword(const uint16_t *start, int num_u16)
> @@ -212,13 +215,14 @@ static void do_send(int fd, char *buf, int len)
> if (ret != len)
> error(1, 0, "write: %u %u", ret, len);
>
> - fprintf(stderr, "tx: %u\n", ret);
> + if (!cfg_drop)
> + fprintf(stderr, "tx: %u\n", ret);
> }
>
> -static int do_tx(void)
> +static int do_tx(bool burst)
> {
> const int one = 1;
> - int fd, len;
> + int i, fd, len;
>
> fd = socket(PF_PACKET, cfg_use_dgram ? SOCK_DGRAM : SOCK_RAW, 0);
> if (fd == -1)
> @@ -242,6 +246,10 @@ static int do_tx(void)
>
> do_send(fd, tbuf, len);
>
> + if (burst)
> + for (i = 0; i < BURST_CNT; i++)
> + do_send(fd, tbuf, len);
> +
> if (close(fd))
> error(1, errno, "close t");
>
> @@ -290,6 +298,7 @@ static void do_rx(int fd, int expected_len, char *expected)
> static int setup_sniffer(void)
> {
> struct timeval tv = { .tv_usec = 100 * 1000 };
> + const int one = 1;
> int fd;
>
> fd = socket(PF_PACKET, SOCK_RAW, 0);
> @@ -299,6 +308,10 @@ static int setup_sniffer(void)
> if (setsockopt(fd, SOL_SOCKET, SO_RCVTIMEO, &tv, sizeof(tv)))
> error(1, errno, "setsockopt rcv timeout");
>
> + if (cfg_drop)
> + if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF, &one, sizeof(one)))
> + error(1, errno, "setsockopt SO_RCVBUF");
> +
> pair_udp_setfilter(fd);
> do_bind(fd);
>
> @@ -309,7 +322,7 @@ static void parse_opts(int argc, char **argv)
> {
> int c;
>
> - while ((c = getopt(argc, argv, "bcCdgl:qt:vV")) != -1) {
> + while ((c = getopt(argc, argv, "bcCdDgl:qt:vV")) != -1) {
> switch (c) {
> case 'b':
> cfg_use_bind = true;
> @@ -323,6 +336,9 @@ static void parse_opts(int argc, char **argv)
> case 'd':
> cfg_use_dgram = true;
> break;
> + case 'D':
> + cfg_drop = true;
> + break;
> case 'g':
> cfg_use_gso = true;
> break;
> @@ -367,11 +383,23 @@ static void check_packet_stats(int fd)
> if (getsockopt(fd, SOL_PACKET, PACKET_STATISTICS, &st, &len))
> error(1, errno, "getsockopt packet statistics");
>
> - if (st.tp_packets != 1)
> - error(1, 0, "stats: tp_packets %u != 1", st.tp_packets);
> + if (cfg_drop) {
> + /* PACKET_STATISTICS reports all packets seen (including
> + * drops) in tp_packets
> + */
> + if (st.tp_packets < st.tp_drops)
> + error(1, 0, "stats: tp_packets %u < tp_drops %u",
> + st.tp_packets, st.tp_drops);
>
> - if (st.tp_drops != 0)
> - error(1, 0, "stats: tp_drops %u != 0", st.tp_drops);
> + if (st.tp_drops == 0)
> + error(1, 0, "stats: expected drops but tp_drops == 0");
> + } else {
> + if (st.tp_packets != 1)
> + error(1, 0, "stats: tp_packets %u != 1", st.tp_packets);
> +
> + if (st.tp_drops != 0)
> + error(1, 0, "stats: tp_drops %u != 0", st.tp_drops);
> + }
>
> /* verify clear on read */
> memset(&st, 0xff, sizeof(st));
> @@ -394,7 +422,12 @@ static void run_test(void)
> fdr = setup_rx();
> fds = setup_sniffer();
>
> - total_len = do_tx();
> + total_len = do_tx(cfg_drop);
only if respinning: no need to pass global cfg_.. variables through
function arguments.
> +
> + if (cfg_drop) {
> + check_packet_stats(fds);
> + goto out;
> + }
can this not use the check_packet_stats added in the previous patch
right below?
>
> /* BPF filter accepts only this length, vlan changes MAC */
> if (cfg_payload_len == DATA_LEN && !cfg_use_vlan) {
> @@ -405,6 +438,7 @@ static void run_test(void)
>
> do_rx(fdr, cfg_payload_len, tbuf + total_len - cfg_payload_len);
>
> +out:
> if (close(fds))
> error(1, errno, "close s");
> if (close(fdr))
> diff --git a/tools/testing/selftests/net/psock_snd.sh b/tools/testing/selftests/net/psock_snd.sh
> index 1cbfeb5052ec..b6ef12fad5d5 100755
> --- a/tools/testing/selftests/net/psock_snd.sh
> +++ b/tools/testing/selftests/net/psock_snd.sh
> @@ -92,4 +92,9 @@ echo "raw gso max size"
> echo "raw gso max size + 1 (expected to fail)"
> (! ./in_netns.sh ./psock_snd -v -c -g -l "${max_mss_exceeds}")
>
> +# test drops statistics
> +
> +echo "test drops statistics"
> +./in_netns.sh ./psock_snd -D
> +
> echo "OK. All tests passed"
> --
> 2.52.0
>
^ permalink raw reply
* Re: [RFC PATCH net-next 1/3] net: phy: add support for disabling PHY-autonomous EEE
From: Andrew Lunn @ 2026-04-03 15:27 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: netdev, Russell King, Florian Fainelli, Heiner Kallweit,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-kernel
In-Reply-To: <20260403090656.733985-2-nb@tipi-net.de>
> + * @autonomous_eee_disabled: Set when autonomous EEE has been disabled via
> + * phy_support_eee(), used to re-apply after PHY soft reset
Thinking ahead to when autonomous EEE is supported, there will be
other reasons to disable it than just phy_support_eee(). So i would
not say this here.
> * @eee_cfg: User configuration of EEE
> * @lp_advertising: Current link partner advertised linkmodes
> * @host_interfaces: PHY interface modes supported by host
> @@ -739,6 +741,7 @@ struct phy_device {
> __ETHTOOL_DECLARE_LINK_MODE_MASK(eee_disabled_modes);
> bool enable_tx_lpi;
> bool eee_active;
> + bool autonomous_eee_disabled;
> struct eee_config eee_cfg;
>
> /* Host supported PHY interface types. Should be ignored if empty. */
> @@ -1359,6 +1362,21 @@ struct phy_driver {
> void (*get_stats)(struct phy_device *dev,
> struct ethtool_stats *stats, u64 *data);
>
> + /**
> + * @disable_autonomous_eee: Disable PHY-autonomous EEE
> + *
> + * Some PHYs manage EEE LPI autonomously without forwarding LPI
> + * signaling to the MAC.
My understanding is that LPI is always from the MAC to the PHY?
> + * Called by phy_support_eee() when the MAC indicates it supports
> + * EEE. PHY drivers that implement autonomous EEE should provide
> + * this callback.
Again, there will be other reasons to call this, than just
phy_support_eee().
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [RFC PATCH net-next 2/3] net: phy: broadcom: implement .disable_autonomous_eee for BCM54xx
From: Andrew Lunn @ 2026-04-03 15:29 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: netdev, Russell King, Florian Fainelli,
Broadcom internal kernel review list, Heiner Kallweit,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
linux-kernel
In-Reply-To: <20260403090656.733985-3-nb@tipi-net.de>
On Fri, Apr 03, 2026 at 11:06:52AM +0200, Nicolai Buchwitz wrote:
> Disable AutogrEEEn mode on BCM54210E when the MAC indicates EEE support
> via phy_support_eee(). In AutogrEEEn mode the PHY manages LPI
At the driver level, it should not matter why this is called, what is
happening above. It should just do what it is told.
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [RFC PATCH net-next 0/3] net: phy: add support for disabling autonomous EEE
From: Andrew Lunn @ 2026-04-03 15:31 UTC (permalink / raw)
To: Nicolai Buchwitz; +Cc: netdev, Russell King, Florian Fainelli
In-Reply-To: <20260403090656.733985-1-nb@tipi-net.de>
On Fri, Apr 03, 2026 at 11:06:50AM +0200, Nicolai Buchwitz wrote:
> Some PHYs implement autonomous EEE where the PHY manages LPI signaling
> without forwarding it to the MAC. This conflicts with MACs that
> implement their own LPI control via phylink's mac_enable_tx_lpi /
> mac_disable_tx_lpi callbacks.
>
> This series adds a .disable_autonomous_eee callback to struct phy_driver
> and calls it from phy_support_eee(). When a MAC indicates it supports
> EEE, the PHY's autonomous EEE is automatically disabled so the MAC can
> manage LPI entry/exit. The setting is persisted across suspend/resume
> by re-applying it in phy_init_hw() after soft reset, following the same
> pattern suggested by Russell King for PHY tunables [1].
I think the general direction of these patches are good, just some
nitpicks to sort out.
Thanks
Andrew
^ permalink raw reply
* [PATCH iwl-net] idpf: fix read_dev_clk_lock spinlock init in idpf_ptp_init()
From: Emil Tantilov @ 2026-04-03 15:35 UTC (permalink / raw)
To: intel-wired-lan
Cc: netdev, anthony.l.nguyen, aleksandr.loktionov, przemyslaw.kitszel,
andrew+netdev, davem, edumazet, kuba, pabeni, richardcochran,
milena.olech, jacob.e.keller, konstantin.ilichev
In idpf_ptp_init(), read_dev_clk_lock is initialized after
ptp_schedule_worker() had already been called (and after
idpf_ptp_settime64() could reach the lock). The PTP aux worker
fires immediately upon scheduling and can call into
idpf_ptp_read_src_clk_reg_direct(), which takes
spin_lock(&ptp->read_dev_clk_lock) on an uninitialized lock, triggering
the lockdep "non-static key" warning:
[12973.796587] idpf 0000:83:00.0: Device HW Reset initiated
[12974.094507] INFO: trying to register non-static key.
...
[12974.097208] Call Trace:
[12974.097213] <TASK>
[12974.097218] dump_stack_lvl+0x93/0xe0
[12974.097234] register_lock_class+0x4c4/0x4e0
[12974.097249] ? __lock_acquire+0x427/0x2290
[12974.097259] __lock_acquire+0x98/0x2290
[12974.097272] lock_acquire+0xc6/0x310
[12974.097281] ? idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf]
[12974.097311] ? lockdep_hardirqs_on_prepare+0xde/0x190
[12974.097318] ? finish_task_switch.isra.0+0xd2/0x350
[12974.097330] ? __pfx_ptp_aux_kworker+0x10/0x10 [ptp]
[12974.097343] _raw_spin_lock+0x30/0x40
[12974.097353] ? idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf]
[12974.097373] idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf]
[12974.097391] ? kthread_worker_fn+0x88/0x3d0
[12974.097404] ? kthread_worker_fn+0x4e/0x3d0
[12974.097411] idpf_ptp_update_cached_phctime+0x26/0x120 [idpf]
[12974.097428] ? _raw_spin_unlock_irq+0x28/0x50
[12974.097436] idpf_ptp_do_aux_work+0x15/0x20 [idpf]
[12974.097454] ptp_aux_kworker+0x20/0x40 [ptp]
[12974.097464] kthread_worker_fn+0xd5/0x3d0
[12974.097474] ? __pfx_kthread_worker_fn+0x10/0x10
[12974.097482] kthread+0xf4/0x130
[12974.097489] ? __pfx_kthread+0x10/0x10
[12974.097498] ret_from_fork+0x32c/0x410
[12974.097512] ? __pfx_kthread+0x10/0x10
[12974.097519] ret_from_fork_asm+0x1a/0x30
[12974.097540] </TASK>
Move the call to spin_lock_init() up a bit to make sure read_dev_clk_lock
is not touched before it's been initialized.
Fixes: 5cb8805d2366 ("idpf: negotiate PTP capabilities and get PTP clock")
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Reviewed-by: Madhu Chittim <madhu.chittim@intel.com>
---
drivers/net/ethernet/intel/idpf/idpf_ptp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/idpf/idpf_ptp.c b/drivers/net/ethernet/intel/idpf/idpf_ptp.c
index eec91c4f0a75..4a51d2727547 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_ptp.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_ptp.c
@@ -952,6 +952,8 @@ int idpf_ptp_init(struct idpf_adapter *adapter)
goto free_ptp;
}
+ spin_lock_init(&adapter->ptp->read_dev_clk_lock);
+
err = idpf_ptp_create_clock(adapter);
if (err)
goto free_ptp;
@@ -977,8 +979,6 @@ int idpf_ptp_init(struct idpf_adapter *adapter)
goto remove_clock;
}
- spin_lock_init(&adapter->ptp->read_dev_clk_lock);
-
pci_dbg(adapter->pdev, "PTP init successful\n");
return 0;
--
2.37.3
^ permalink raw reply related
* RE: [PATCH iwl-net] idpf: fix read_dev_clk_lock spinlock init in idpf_ptp_init()
From: Loktionov, Aleksandr @ 2026-04-03 15:36 UTC (permalink / raw)
To: Tantilov, Emil S, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Nguyen, Anthony L, Kitszel, Przemyslaw,
andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com, richardcochran@gmail.com,
Olech, Milena, Keller, Jacob E, Ilichev, Konstantin
In-Reply-To: <20260403153538.11516-1-emil.s.tantilov@intel.com>
> -----Original Message-----
> From: Tantilov, Emil S <emil.s.tantilov@intel.com>
> Sent: Friday, April 3, 2026 5:36 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; andrew+netdev@lunn.ch;
> davem@davemloft.net; edumazet@google.com; kuba@kernel.org;
> pabeni@redhat.com; richardcochran@gmail.com; Olech, Milena
> <milena.olech@intel.com>; Keller, Jacob E <jacob.e.keller@intel.com>;
> Ilichev, Konstantin <konstantin.ilichev@intel.com>
> Subject: [PATCH iwl-net] idpf: fix read_dev_clk_lock spinlock init in
> idpf_ptp_init()
>
> In idpf_ptp_init(), read_dev_clk_lock is initialized after
> ptp_schedule_worker() had already been called (and after
> idpf_ptp_settime64() could reach the lock). The PTP aux worker fires
> immediately upon scheduling and can call into
> idpf_ptp_read_src_clk_reg_direct(), which takes
> spin_lock(&ptp->read_dev_clk_lock) on an uninitialized lock,
> triggering the lockdep "non-static key" warning:
>
> [12973.796587] idpf 0000:83:00.0: Device HW Reset initiated
> [12974.094507] INFO: trying to register non-static key.
> ...
> [12974.097208] Call Trace:
> [12974.097213] <TASK>
> [12974.097218] dump_stack_lvl+0x93/0xe0 [12974.097234]
> register_lock_class+0x4c4/0x4e0 [12974.097249] ?
> __lock_acquire+0x427/0x2290 [12974.097259] __lock_acquire+0x98/0x2290
> [12974.097272] lock_acquire+0xc6/0x310 [12974.097281] ?
> idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf] [12974.097311] ?
> lockdep_hardirqs_on_prepare+0xde/0x190
> [12974.097318] ? finish_task_switch.isra.0+0xd2/0x350
> [12974.097330] ? __pfx_ptp_aux_kworker+0x10/0x10 [ptp] [12974.097343]
> _raw_spin_lock+0x30/0x40 [12974.097353] ?
> idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf] [12974.097373]
> idpf_ptp_read_src_clk_reg+0xb7/0x150 [idpf] [12974.097391] ?
> kthread_worker_fn+0x88/0x3d0 [12974.097404] ?
> kthread_worker_fn+0x4e/0x3d0 [12974.097411]
> idpf_ptp_update_cached_phctime+0x26/0x120 [idpf] [12974.097428] ?
> _raw_spin_unlock_irq+0x28/0x50 [12974.097436]
> idpf_ptp_do_aux_work+0x15/0x20 [idpf] [12974.097454]
> ptp_aux_kworker+0x20/0x40 [ptp] [12974.097464]
> kthread_worker_fn+0xd5/0x3d0 [12974.097474] ?
> __pfx_kthread_worker_fn+0x10/0x10 [12974.097482] kthread+0xf4/0x130
> [12974.097489] ? __pfx_kthread+0x10/0x10 [12974.097498]
> ret_from_fork+0x32c/0x410 [12974.097512] ? __pfx_kthread+0x10/0x10
> [12974.097519] ret_from_fork_asm+0x1a/0x30 [12974.097540] </TASK>
>
> Move the call to spin_lock_init() up a bit to make sure
> read_dev_clk_lock is not touched before it's been initialized.
>
> Fixes: 5cb8805d2366 ("idpf: negotiate PTP capabilities and get PTP
> clock")
> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
> Reviewed-by: Madhu Chittim <madhu.chittim@intel.com>
> ---
> drivers/net/ethernet/intel/idpf/idpf_ptp.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/idpf/idpf_ptp.c
> b/drivers/net/ethernet/intel/idpf/idpf_ptp.c
> index eec91c4f0a75..4a51d2727547 100644
> --- a/drivers/net/ethernet/intel/idpf/idpf_ptp.c
> +++ b/drivers/net/ethernet/intel/idpf/idpf_ptp.c
> @@ -952,6 +952,8 @@ int idpf_ptp_init(struct idpf_adapter *adapter)
> goto free_ptp;
> }
>
> + spin_lock_init(&adapter->ptp->read_dev_clk_lock);
> +
> err = idpf_ptp_create_clock(adapter);
> if (err)
> goto free_ptp;
> @@ -977,8 +979,6 @@ int idpf_ptp_init(struct idpf_adapter *adapter)
> goto remove_clock;
> }
>
> - spin_lock_init(&adapter->ptp->read_dev_clk_lock);
> -
> pci_dbg(adapter->pdev, "PTP init successful\n");
>
> return 0;
> --
> 2.37.3
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* Re: [net-next 3/3] selftests/net: Test PACKET_AUXDATA
From: Willem de Bruijn @ 2026-04-03 15:37 UTC (permalink / raw)
To: Joe Damato, netdev, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Shuah Khan
Cc: andrew+netdev, linux-kernel, willemb, Joe Damato, linux-kselftest
In-Reply-To: <20260402232203.2004496-4-joe@dama.to>
Joe Damato wrote:
> Extend the packet socket selftest, adding a recvmsg path, to test
> PACKET_AUXDATA. Check basic attributes of tpacket_auxdata.
>
> Signed-off-by: Joe Damato <joe@dama.to>
> ---
> tools/testing/selftests/net/psock_snd.c | 57 ++++++++++++++++++++++--
> tools/testing/selftests/net/psock_snd.sh | 5 +++
> 2 files changed, 59 insertions(+), 3 deletions(-)
>
> diff --git a/tools/testing/selftests/net/psock_snd.c b/tools/testing/selftests/net/psock_snd.c
> index 7bbce274b9f0..682e0afe364d 100644
> --- a/tools/testing/selftests/net/psock_snd.c
> +++ b/tools/testing/selftests/net/psock_snd.c
> @@ -40,6 +40,7 @@ static bool cfg_use_qdisc_bypass;
> static bool cfg_use_vlan;
> static bool cfg_use_vnet;
> static bool cfg_drop;
> +static bool cfg_aux_data;
>
> static char *cfg_ifname = "lo";
> static int cfg_mtu = 1500;
> @@ -281,9 +282,26 @@ static int setup_rx(void)
>
> static void do_rx(int fd, int expected_len, char *expected)
> {
> + char cmsg_buf[1024] = {};
> + struct msghdr msg = {};
> + struct iovec iov[1];
> int ret;
>
> - ret = recv(fd, rbuf, sizeof(rbuf), 0);
> + if (cfg_aux_data) {
> + iov[0].iov_base = rbuf;
> + iov[0].iov_len = sizeof(rbuf);
> +
> + msg.msg_iov = iov;
> + msg.msg_iovlen = 1;
> +
> + msg.msg_control = cmsg_buf;
> + msg.msg_controllen = sizeof(cmsg_buf);
> +
> + ret = recvmsg(fd, &msg, 0);
> + } else {
> + ret = recv(fd, rbuf, sizeof(rbuf), 0);
> + }
> +
> if (ret == -1)
> error(1, errno, "recv");
> if (ret != expected_len)
> @@ -292,6 +310,31 @@ static void do_rx(int fd, int expected_len, char *expected)
> if (memcmp(rbuf, expected, ret))
> error(1, 0, "recv: data mismatch");
>
> + if (cfg_aux_data) {
> + struct cmsghdr *cmsg = CMSG_FIRSTHDR(&msg);
> + struct tpacket_auxdata *adata;
> +
> + if (!cmsg)
> + error(1, 0, "auxdata null");
> +
> + if (cmsg->cmsg_level != SOL_PACKET)
> + error(1, 0, "cmsg_level != SOL_PACKET");
> +
> + if (cmsg->cmsg_type != PACKET_AUXDATA)
> + error(1, 0, "cmsg_type != PACKET_AUXDATA");
> +
> + adata = (struct tpacket_auxdata *)CMSG_DATA(cmsg);
> +
> + if (adata->tp_net != ETH_HLEN)
> + error(1, 0, "cmsg tp_net != ETH_HLEN");
> +
> + if (adata->tp_len != expected_len)
> + error(1, 0, "cmsg tp_len != %u", expected_len);
> +
> + if (adata->tp_snaplen != expected_len)
> + error(1, 0, "cmsg tp_snaplen != %u", expected_len);
> + }
> +
> fprintf(stderr, "rx: %u\n", ret);
> }
>
> @@ -312,6 +355,10 @@ static int setup_sniffer(void)
> if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF, &one, sizeof(one)))
> error(1, errno, "setsockopt SO_RCVBUF");
>
> + if (cfg_aux_data)
> + if (setsockopt(fd, SOL_PACKET, PACKET_AUXDATA, &one, sizeof(one)))
> + error(1, errno, "setsockopt PACKET_AUXDATA");
> +
> pair_udp_setfilter(fd);
> do_bind(fd);
>
> @@ -322,8 +369,11 @@ static void parse_opts(int argc, char **argv)
> {
> int c;
>
> - while ((c = getopt(argc, argv, "bcCdDgl:qt:vV")) != -1) {
> + while ((c = getopt(argc, argv, "abcCdDgl:qt:vV")) != -1) {
> switch (c) {
> + case 'a':
> + cfg_aux_data = true;
> + break;
> case 'b':
> cfg_use_bind = true;
> break;
> @@ -436,7 +486,8 @@ static void run_test(void)
> check_packet_stats(fds);
> }
>
> - do_rx(fdr, cfg_payload_len, tbuf + total_len - cfg_payload_len);
> + if (!cfg_aux_data)
> + do_rx(fdr, cfg_payload_len, tbuf + total_len - cfg_payload_len);
Slight preference to instead detect that this is a read not from a packet
socket and skip the cmsg processing inside do_rx as a result.
A roundabout way would be using getsockname. Simpler may be just to pass a new
boolean to do_rx is_psock or os.
^ permalink raw reply
* Re: [PATCH] net: qualcomm: qca_uart: report the consumed byte on RX skb allocation failure
From: Simon Horman @ 2026-04-03 15:37 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Stefan Wahren, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel, stable
In-Reply-To: <20260402071207.4036-1-pengpeng@iscas.ac.cn>
On Thu, Apr 02, 2026 at 03:12:07PM +0800, Pengpeng Hou wrote:
> qca_tty_receive() consumes each input byte before checking whether a
> completed frame needs a fresh receive skb. When the current byte completes
> a frame, the driver delivers that frame and then allocates a new skb for
> the next one.
>
> If that allocation fails, the current code returns i even though data[i]
> has already been consumed and may already have completed the delivered
> frame. Since serdev interprets the return value as the number of accepted
> bytes, this under-reports progress by one byte and can replay the final
> byte of the completed frame into a fresh parser state on the next call.
>
> Return i + 1 in that failure path so the accepted-byte count matches the
> actual receive-state progress.
>
> Fixes: dfc768fbe618 ("net: qualcomm: add QCA7000 UART driver")
> Cc: stable@vger.kernel.org
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* Re: [PATCH net-next] eth: remove the driver for acenic / tigon1&2
From: Bjorn Helgaas @ 2026-04-03 15:40 UTC (permalink / raw)
To: Gary Guo
Cc: Jakub Kicinski, davem, netdev, edumazet, pabeni, andrew+netdev,
horms, jes, chenhuacai, kernel, tsbogend, James.Bottomley, deller,
maddy, mpe, npiggin, chleroy, hca, gor, agordeev, borntraeger,
svens, bhelgaas, dakr, kwilczynski, ojeda, boqun, bjorn3_gh,
lossin, a.hindborg, aliceryhl, tmgross, ebiggers, ardb, tiwai,
tytso, enelsonmoore, martin.petersen, jirislaby, gregkh, geert,
herbert, vineethr, lirongqing, kshk, vadim.fedorenko, dong100,
wangruikang, hkallweit1, kees, loongarch, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-pci, rust-for-linux
In-Reply-To: <DHJKGY0F52GL.14FQPOWWO0F77@garyguo.net>
On Fri, Apr 03, 2026 at 02:50:32PM +0100, Gary Guo wrote:
> On Thu Apr 2, 2026 at 7:30 PM BST, Jakub Kicinski wrote:
> > The entire git history for this driver looks like tree-wide
> > and automated cleanups. There's even more coming now with
> > AI, so let's try to delete it instead.
> > +++ b/include/linux/pci_ids.h
> > @@ -1809,8 +1809,6 @@
> > /* formerly Platform Tech */
> > #define PCI_DEVICE_ID_ESS_ESS0100 0x0100
> >
> > -#define PCI_VENDOR_ID_ALTEON 0x12ae
> > -
> > #define PCI_SUBVENDOR_ID_CONNECT_TECH 0x12c4
> > #define PCI_SUBDEVICE_ID_CONNECT_TECH_BH8_232 0x0001
> > #define PCI_SUBDEVICE_ID_CONNECT_TECH_BH4_232 0x0002
> Does the PCI ID needs to be removed? There was a similar change that
> I recalled and the discussion eventually leads to ID not being
> removed.
> https://lore.kernel.org/all/20260123033233.16906-1-enelsonmoore@gmail.com/
I don't think there is value in removing the PCI_VENDOR_ID_ALTEON
definition.
^ permalink raw reply
* Re: [net-next,13/15] ice: add support for unmanaged DPLL on E830 NIC
From: Tony Nguyen @ 2026-04-03 15:44 UTC (permalink / raw)
To: Paolo Abeni
Cc: andriy.shevchenko, pmenzel, aleksandr.loktionov, mika.westerberg,
mbloch, saeedm, piotr.kwapulinski, sx.rinitha, kuba,
grzegorz.nitka, netdev, przemyslaw.kitszel, arkadiusz.kubalewski,
tariqt, davem, dima.ruinskiy, bhelgaas, andrew+netdev, lukas,
jacob.e.keller, richardcochran, takkozu, enjuk,
maximilianpezzullo, joe, przemyslaw.korba, leon, vgrinber,
linux-pci, sunithax.d.mekala, corbet, vinicius.gomes,
ilpo.jarvinen, edumazet, linux-doc, kohei.enju, kohei, horms,
avigailx.dahan
In-Reply-To: <20260402102616.177883-1-pabeni@redhat.com>
On 4/2/2026 3:26 AM, Paolo Abeni wrote:
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
>
> For local reproduction steps see https://netdev-ai.bots.linux.dev/ai-local.html
> ---
> ice: add support for unmanaged DPLL on E830 NIC
>
> Hardware variants of E830 may support an unmanaged DPLL where the
> configuration is hardcoded within the hardware and firmware, meaning
> users cannot modify settings. However, users are able to check the DPLL
> lock status and obtain configuration information through the Linux DPLL
> and devlink health subsystem.
>
>> diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.c b/drivers/net/ethernet/intel/ice/ice_dpll.c
>> index 62f75701d652..2a9eb233dbf4 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_dpll.c
>> +++ b/drivers/net/ethernet/intel/ice/ice_dpll.c
>
> [ ... ]
>
>> @@ -3148,12 +3176,15 @@ ice_dpll_init_direct_pins(struct ice_pf *pf, bool cgu,
>> int ret;
>>
>> ret = ice_dpll_get_pins(pf, pins, start_idx, count, pf->dplls.clock_id);
>> - if (ret)
>> + if (!cgu || ret)
>> return ret;
>> - if (cgu) {
>> +
>> + if (first) {
>> ret = ice_dpll_register_pins(first, pins, ops, count);
>> if (ret)
>> goto release_pins;
>> + }
>> + if (second) {
>> ret = ice_dpll_register_pins(second, pins, ops, count);
>> if (ret)
>> goto unregister_first;
>> @@ -3162,7 +3193,8 @@ ice_dpll_init_direct_pins(struct ice_pf *pf, bool cgu,
>> return 0;
>>
>> unregister_first:
>> - ice_dpll_unregister_pins(first, pins, ops, count);
>> + if (first)
>> + ice_dpll_unregister_pins(first, pins, ops, count);
>> release_pins:
>> ice_dpll_release_pins(pins, count);
>> return ret;
>
> NULL checks were added to ice_dpll_init_direct_pins for handling unmanaged
> DPLL initialization where only one DPLL device is active. However, is the
> corresponding cleanup function ice_dpll_deinit_direct_pins missing the same
> NULL checks?
>
> In unmanaged mode, only pf->dplls.pps.dpll is initialized while
> pf->dplls.eec.dpll remains NULL. When ice_dpll_init_pins calls
> ice_dpll_init_direct_pins(pf, true, outputs, count, num_outputs,
> output_ops, eec.dpll, pps.dpll), if this second call (for output pins)
> fails, the error path calls ice_dpll_deinit_direct_pins(pf, true, ...,
> pps.dpll, eec.dpll).
>
> Looking at ice_dpll_deinit_direct_pins:
>
> static void ice_dpll_deinit_direct_pins(struct ice_pf *pf, bool cgu,
> struct ice_dpll_pin *pins, int count,
> const struct dpll_pin_ops *ops,
> struct dpll_device *first,
> struct dpll_device *second)
> {
> if (cgu) {
> ice_dpll_unregister_pins(first, pins, ops, count);
> ice_dpll_unregister_pins(second, pins, ops, count);
> }
> ice_dpll_release_pins(pins, count);
> }
>
> When cgu=true and second=NULL, ice_dpll_unregister_pins is called with
> dpll=NULL. Then dpll_pin_unregister(dpll, pin) dereferences dpll with
> xa_empty(&dpll->pin_refs), causing a NULL pointer dereference.
>
> Shouldn't ice_dpll_deinit_direct_pins add NULL checks for first and second,
> matching the guards you added in ice_dpll_init_direct_pins?
>
>> diff --git a/drivers/net/ethernet/intel/ice/ice_dpll.h b/drivers/net/ethernet/intel/ice/ice_dpll.h
>> index ae42cdea0ee1..2c98b6c6deb0 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_dpll.h
>> +++ b/drivers/net/ethernet/intel/ice/ice_dpll.h
>
> [ ... ]
>
>> @@ -173,3 +181,5 @@ static inline void ice_dpll_deinit(struct ice_pf *pf) { }
>> #define ICE_CGU_R11_SYNCE_S_BYP_CLK GENMASK(6, 1)
>>
>> #define ICE_CGU_BYPASS_MUX_OFFSET_E825C 3
>> +#define ICE_DPLL_UNMANAGED_PIN_NUM 4
>> +#define ICE_DPLL_IN_ESYNC_ENABLED ICE_AQC_GET_CGU_IN_CFG_FLG2_ESYNC_EN
>
> This isn't a bug, but ICE_DPLL_UNMANAGED_PIN_NUM is defined but never
> used. Looking at the unmanaged pin descriptors, ice_e830_unmanaged_inputs
> has 1 entry and ice_e830_unmanaged_outputs has 2 entries (totaling 3 pins,
> not 4).
Hi Paolo,
We're working on changes to resolve these issues.
Thanks,
Tony
^ permalink raw reply
* Re: [PATCH] usb: rtl8150: avoid using uninitialized CSCR value
From: Simon Horman @ 2026-04-03 15:45 UTC (permalink / raw)
To: Morduan Zang
Cc: Petko Manolov, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, linux-usb, netdev, linux-kernel,
syzbot+9db6c624635564ad813c
In-Reply-To: <93FF85BB9F33CD2B+20260402070743.20641-1-zhangdandan@uniontech.com>
On Thu, Apr 02, 2026 at 03:07:43PM +0800, Morduan Zang wrote:
> Check get_registers() when reading CSCR in set_carrier().
> If the control transfer fails, don't use the stack value.
>
> Reported-by: syzbot+9db6c624635564ad813c@syzkaller.appspotmail.com
> Closes: https://syzkaller.appspot.com/bug?extid=9db6c624635564ad813c
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Morduan Zang <zhangdandan@uniontech.com>
> ---
> drivers/net/usb/rtl8150.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
> index 4cda0643afb6..7e32726d3e6f 100644
> --- a/drivers/net/usb/rtl8150.c
> +++ b/drivers/net/usb/rtl8150.c
> @@ -722,7 +722,11 @@ static void set_carrier(struct net_device *netdev)
> rtl8150_t *dev = netdev_priv(netdev);
> short tmp;
>
> - get_registers(dev, CSCR, 2, &tmp);
> + if (get_registers(dev, CSCR, 2, &tmp) < 0) {
> + netif_carrier_off(netdev);
> + return;
> + }
> +
> if (tmp & CSCR_LINK_STATUS)
> netif_carrier_on(netdev);
> else
I wonder if we can handle this a bit more succinctly,
while still making it clear that the error is handled.
Something like this:
diff --git a/drivers/net/usb/rtl8150.c b/drivers/net/usb/rtl8150.c
index 4cda0643afb6..816759ced56c 100644
--- a/drivers/net/usb/rtl8150.c
+++ b/drivers/net/usb/rtl8150.c
@@ -722,7 +722,8 @@ static void set_carrier(struct net_device *netdev)
rtl8150_t *dev = netdev_priv(netdev);
short tmp;
- get_registers(dev, CSCR, 2, &tmp);
+ if (get_registers(dev, CSCR, 2, &tmp) < 0)
+ tmp = 0;
if (tmp & CSCR_LINK_STATUS)
netif_carrier_on(netdev);
else
^ permalink raw reply related
* RE: [PATCH net] net: phy: micrel: Fix MMD register access during SPD in ksz9131_resume()
From: Ovidiu Panait @ 2026-04-03 15:48 UTC (permalink / raw)
To: Russell King
Cc: andrew@lunn.ch, hkallweit1@gmail.com, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com, Biju Das,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <ac_Udvtrj0Bl-6wl@shell.armlinux.org.uk>
Hi,
>
> On Fri, Apr 03, 2026 at 11:17:38AM +0000, Ovidiu Panait wrote:
> > During system suspend, phy_suspend() puts the PHY into Software Power-
> Down
> > (SPD) by setting the BMCR_PDOWN bit in MII_BMCR. According to the
> KSZ9131
> > datasheet, MMD register access is restricted during SPD:
> >
> > - Only access to the standard registers (0 through 31) is supported.
> > - Access to MMD address spaces other than MMD address space 1 is
> > possible if the spd_clock_gate_override bit is set.
> > - Access to MMD address space 1 is not possible.
> >
> > However, ksz9131_resume() calls ksz9131_config_rgmii_delay() before
> > kszphy_resume() clears BMCR_PDOWN. This means MMD registers are accessed
> > while the PHY is still in SPD, contrary to the datasheet.
> >
> > Additionally, on platforms where the PHY loses power during suspend
> > (e.g. RZ/G3E), all settings from ksz9131_config_init(), not just the
> > RGMII delays, are lost and need to be restored. When the MAC driver
> > sets mac_managed_pm (e.g. stmmac), mdio_bus_phy_resume() is skipped,
> > so phy_init_hw() (which calls config_init to restore all PHY settings)
> > is never invoked during resume.
> >
> > Fix this by replacing the RGMII delay restoration with a call to
> > phy_init_hw(), which takes the PHY out of SPD and performs full
> > reinitialization.
> >
> > Fixes: f25a7eaa897f ("net: phy: micrel: Add ksz9131_resume()")
> > Signed-off-by: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> > ---
> > drivers/net/phy/micrel.c | 9 +++++++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
> > index 2aa1dedd21b8..4236dbf4ad6b 100644
> > --- a/drivers/net/phy/micrel.c
> > +++ b/drivers/net/phy/micrel.c
> > @@ -6016,8 +6016,13 @@ static int lan8841_suspend(struct phy_device
> *phydev)
> >
> > static int ksz9131_resume(struct phy_device *phydev)
> > {
> > - if (phydev->suspended && phy_interface_is_rgmii(phydev))
> > - ksz9131_config_rgmii_delay(phydev);
> > + int ret;
> > +
> > + if (phydev->suspended) {
> > + ret = phy_init_hw(phydev);
> > + if (ret)
> > + return ret;
> > + }
> >
> > return kszphy_resume(phydev);
> > }
>
> mdio_bus_phy_resume():
>
> ret = phy_init_hw(phydev);
> if (ret < 0)
> return ret;
>
> ret = phy_resume(phydev);
> if (ret < 0)
> return ret;
>
> where phy_resume() calls your resume function.
>
> If a MAC driver is handling suspend/resume by setting
> phydev->mac_managed_pm then maybe the MAC driver should also be
> issuing phy_init_hw() before calling phy_resume() ?
>
> Which MAC driver are you seeing a problem with?
>
On my board the KSZ9131RNX PHY is paired to stmmac.
I could add phy_init_hw() before the phylink_prepare_resume() call, which
does the phy_resume() and remove the ksz9131_config_rgmii_delay() call from
ksz9131_resume(), as it is not correct/complete.
Ovidiu
> --
> RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
> FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
^ permalink raw reply
* Re: [PATCH net v2] ipvs: fix NULL deref in ip_vs_add_service error path
From: Julian Anastasov @ 2026-04-03 15:50 UTC (permalink / raw)
To: Weiming Shi
Cc: Simon Horman, Pablo Neira Ayuso, Florian Westphal,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Phil Sutter, netdev, lvs-devel, netfilter-devel, coreteam,
Xiang Mei
In-Reply-To: <20260401075800.3344266-2-bestswngs@gmail.com>
Hello,
On Wed, 1 Apr 2026, Weiming Shi wrote:
> When ip_vs_bind_scheduler() succeeds in ip_vs_add_service(), the local
> variable sched is set to NULL. If ip_vs_start_estimator() subsequently
> fails, the out_err cleanup calls ip_vs_unbind_scheduler(svc, sched)
> with sched == NULL. ip_vs_unbind_scheduler() passes the cur_sched NULL
> check (because svc->scheduler was set by the successful bind) but then
> dereferences the NULL sched parameter at sched->done_service, causing a
> kernel panic at offset 0x30 from NULL.
>
> Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI
> KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
> RIP: 0010:ip_vs_unbind_scheduler (net/netfilter/ipvs/ip_vs_sched.c:69)
> Call Trace:
> <TASK>
> ip_vs_add_service.isra.0 (net/netfilter/ipvs/ip_vs_ctl.c:1500)
> do_ip_vs_set_ctl (net/netfilter/ipvs/ip_vs_ctl.c:2809)
> nf_setsockopt (net/netfilter/nf_sockopt.c:102)
> ip_setsockopt (net/ipv4/ip_sockglue.c:1427)
> raw_setsockopt (net/ipv4/raw.c:850)
> do_sock_setsockopt (net/socket.c:2322)
> __sys_setsockopt (net/socket.c:2339)
> __x64_sys_setsockopt (net/socket.c:2350)
> do_syscall_64 (arch/x86/entry/syscall_64.c:94)
> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
> </TASK>
>
> Fix by simply not clearing the local sched variable after a successful
> bind. ip_vs_unbind_scheduler() already detects whether a scheduler is
> installed via svc->scheduler, and keeping sched non-NULL ensures the
> error path passes the correct pointer to both ip_vs_unbind_scheduler()
> and ip_vs_scheduler_put().
>
> Fixes: 05f00505a89a ("ipvs: fix crash if scheduler is changed")
> Reported-by: Xiang Mei <xmei5@asu.edu>
> Signed-off-by: Weiming Shi <bestswngs@gmail.com>
Looks good to me, thanks!
Acked-by: Julian Anastasov <ja@ssi.bg>
But the problem popups in more recent kernels (6.2, not 4.2),
when the new error path is added after the ip_vs_start_estimator()
call in commit 705dd3444081 ("ipvs: use kthreads for stats estimation").
> ---
> v2: Remove "sched = NULL" instead of recovering it in out_err (Julian)
>
> net/netfilter/ipvs/ip_vs_ctl.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index 35642de2a0fee..2aaf50f52c8e8 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -1452,7 +1452,6 @@ ip_vs_add_service(struct netns_ipvs *ipvs, struct ip_vs_service_user_kern *u,
> ret = ip_vs_bind_scheduler(svc, sched);
> if (ret)
> goto out_err;
> - sched = NULL;
> }
>
> ret = ip_vs_start_estimator(ipvs, &svc->stats);
> --
> 2.43.0
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH net v3] tipc: fix bc_ackers underflow on duplicate GRP_ACK_MSG
From: Simon Horman @ 2026-04-03 15:51 UTC (permalink / raw)
To: Oleh Konko
Cc: netdev@vger.kernel.org, jmaloy@redhat.com, davem@davemloft.net,
edumazet@google.com, kuba@kernel.org, pabeni@redhat.com,
tipc-discussion@lists.sourceforge.net,
linux-kernel@vger.kernel.org, stable@vger.kernel.org
In-Reply-To: <41a4833f368641218e444fdcff822039.security@1seal.org>
On Thu, Apr 02, 2026 at 09:48:57AM +0000, Oleh Konko wrote:
> The GRP_ACK_MSG handler in tipc_group_proto_rcv() currently decrements
> bc_ackers on every inbound group ACK, even when the same member has
> already acknowledged the current broadcast round.
>
> Because bc_ackers is a u16, a duplicate ACK received after the last
> legitimate ACK wraps the counter to 65535. Once wrapped,
> tipc_group_bc_cong() keeps reporting congestion and later group
> broadcasts on the affected socket stay blocked until the group is
> recreated.
>
> Fix this by ignoring duplicate or stale ACKs before touching bc_acked or
> bc_ackers. This makes repeated GRP_ACK_MSG handling idempotent and
> prevents the underflow path.
>
> Fixes: 2f487712b893 ("tipc: guarantee that group broadcast doesn't bypass group unicast")
> Cc: stable@vger.kernel.org
> Signed-off-by: Oleh Konko <security@1seal.org>
> ---
> v3:
> - correct the Fixes tag to the commit that introduced GRP_ACK_MSG and bc_ackers
>
> v2:
> - make duplicate or stale GRP_ACK_MSG a full no-op via early return
> - place acked in reverse xmas tree style
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* [PATCH v4] netfilter: xt_multiport: validate range encoding in checkentry
From: Ren Wei @ 2026-04-03 15:52 UTC (permalink / raw)
To: netfilter-devel, netdev
Cc: pablo, fw, phil, davem, edumazet, kuba, pabeni, horms,
yasuyuki.kozakai, kaber, yifanwucs, tomapufckgml, yuantan098,
bird, z1652074432, n05ec, enjou1224z
In-Reply-To: <cover.1774624314.git.n05ec@lzu.edu.cn>
ports_match_v1() treats any non-zero pflags entry as the start of a
port range and unconditionally consumes the next ports[] element as
the range end.
The checkentry path currently validates protocol, flags and count, but
it does not validate the range encoding itself. As a result, malformed
rules can mark the last slot as a range start or place two range starts
back to back, leaving ports_match_v1() to step past the last valid
ports[] element while interpreting the rule.
Reject malformed multiport v1 rules in checkentry by validating that
each range start has a following element and that the following element
is not itself marked as another range start.
Fixes: a89ecb6a2ef7 ("[NETFILTER]: x_tables: unify IPv4/IPv6 multiport match")
Reported-by: Yifan Wu <yifanwucs@gmail.com>
Reported-by: Juefei Pu <tomapufckgml@gmail.com>
Co-developed-by: Yuan Tan <yuantan098@gmail.com>
Signed-off-by: Yuan Tan <yuantan098@gmail.com>
Suggested-by: Xin Liu <bird@lzu.edu.cn>
Tested-by: Yuhang Zheng <z1652074432@gmail.com>
Signed-off-by: Ren Wei <n05ec@lzu.edu.cn>
---
Changes in v2:
- drop the selftest patch
- send the fix publicly to netfilter-devel
Changes in v3:
- drop datatype cleanup from the fix
- keep the original check() interface unchanged
- validate malformed range encoding in checkentry
Changes in v4:
- follow Pablo's suggested validation form
- drop inline from multiport_valid_ranges
- reject reversed port ranges
net/netfilter/xt_multiport.c | 34 ++++++++++++++++++++++++++++++----
1 file changed, 30 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/xt_multiport.c b/net/netfilter/xt_multiport.c
index 44a00f5acde8..a1691ff405d3 100644
--- a/net/netfilter/xt_multiport.c
+++ b/net/netfilter/xt_multiport.c
@@ -105,6 +105,28 @@ multiport_mt(const struct sk_buff *skb, struct xt_action_param *par)
return ports_match_v1(multiinfo, ntohs(pptr[0]), ntohs(pptr[1]));
}
+static bool
+multiport_valid_ranges(const struct xt_multiport_v1 *multiinfo)
+{
+ unsigned int i;
+
+ for (i = 0; i < multiinfo->count; i++) {
+ if (!multiinfo->pflags[i])
+ continue;
+
+ if (++i >= multiinfo->count)
+ return false;
+
+ if (multiinfo->pflags[i])
+ return false;
+
+ if (multiinfo->ports[i - 1] > multiinfo->ports[i])
+ return false;
+ }
+
+ return true;
+}
+
static inline bool
check(u_int16_t proto,
u_int8_t ip_invflags,
@@ -127,8 +149,10 @@ static int multiport_mt_check(const struct xt_mtchk_param *par)
const struct ipt_ip *ip = par->entryinfo;
const struct xt_multiport_v1 *multiinfo = par->matchinfo;
- return check(ip->proto, ip->invflags, multiinfo->flags,
- multiinfo->count) ? 0 : -EINVAL;
+ if (!check(ip->proto, ip->invflags, multiinfo->flags, multiinfo->count))
+ return -EINVAL;
+
+ return multiport_valid_ranges(multiinfo) ? 0 : -EINVAL;
}
static int multiport_mt6_check(const struct xt_mtchk_param *par)
@@ -136,8 +160,10 @@ static int multiport_mt6_check(const struct xt_mtchk_param *par)
const struct ip6t_ip6 *ip = par->entryinfo;
const struct xt_multiport_v1 *multiinfo = par->matchinfo;
- return check(ip->proto, ip->invflags, multiinfo->flags,
- multiinfo->count) ? 0 : -EINVAL;
+ if (!check(ip->proto, ip->invflags, multiinfo->flags, multiinfo->count))
+ return -EINVAL;
+
+ return multiport_valid_ranges(multiinfo) ? 0 : -EINVAL;
}
static struct xt_match multiport_mt_reg[] __read_mostly = {
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v2 net] net: lapbether: handle NETDEV_PRE_TYPE_CHANGE
From: Simon Horman @ 2026-04-03 15:55 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S. Miller, Jakub Kicinski, Paolo Abeni, netdev,
eric.dumazet, syzbot+d8c285748fa7292580a9, Martin Schiller,
linux-x25
In-Reply-To: <20260402103519.1201565-1-edumazet@google.com>
On Thu, Apr 02, 2026 at 10:35:19AM +0000, Eric Dumazet wrote:
> lapbeth_data_transmit() expects the underlying device type
> to be ARPHRD_ETHER.
>
> Returning NOTIFY_BAD from lapbeth_device_event() makes sure
> bonding driver can not break this expectation.
>
> Fixes: 872254dd6b1f ("net/bonding: Enable bonding to enslave non ARPHRD_ETHER")
> Reported-by: syzbot+d8c285748fa7292580a9@syzkaller.appspotmail.com
> Closes: https://lore.kernel.org/netdev/69cd22a1.050a0220.70c3a.0002.GAE@google.com/T/#u
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Martin Schiller <ms@dev.tdt.de>
> Cc: linux-x25@vger.kernel.org
> ---
> v2: cache lapbeth_get_x25_dev() result in @lapbeth.
> make sure @lapbeth is set before returning NOTIFY_BAD.
Reviewed-by: Simon Horman <horms@kernel.org>
^ permalink raw reply
* RE: [PATCH net] net: phy: micrel: Fix MMD register access during SPD in ksz9131_resume()
From: Biju Das @ 2026-04-03 15:56 UTC (permalink / raw)
To: Ovidiu Panait, andrew@lunn.ch, hkallweit1@gmail.com,
linux@armlinux.org.uk, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-renesas-soc@vger.kernel.org
In-Reply-To: <TY7P301MB198479332A7A0C00451120EDD35EA@TY7P301MB1984.JPNP301.PROD.OUTLOOK.COM>
> -----Original Message-----
> From: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> Sent: 03 April 2026 14:51
> To: Biju Das <biju.das.jz@bp.renesas.com>; andrew@lunn.ch; hkallweit1@gmail.com; linux@armlinux.org.uk;
> davem@davemloft.net; edumazet@google.com; kuba@kernel.org; pabeni@redhat.com
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; linux-renesas-soc@vger.kernel.org
> Subject: RE: [PATCH net] net: phy: micrel: Fix MMD register access during SPD in ksz9131_resume()
>
>
> > >
> > > Hi,
> > >
> > > >
> > > > Hi Ovidiu Panait,
> > > >
> > > > Thanks for the patch.
> > > >
> > > > > -----Original Message-----
> > > > > From: Ovidiu Panait <ovidiu.panait.rb@renesas.com>
> > > > > Sent: 03 April 2026 12:18
> > > > > Subject: [PATCH net] net: phy: micrel: Fix MMD register access
> > > > > during
> > > > SPD in ksz9131_resume()
> > > > >
> > > > > During system suspend, phy_suspend() puts the PHY into Software
> > > > > Power-
> > > > Down
> > > > > (SPD) by setting the BMCR_PDOWN bit in MII_BMCR. According to
> > > > > the
> > > > KSZ9131 datasheet, MMD register
> > > > > access is restricted during SPD:
> > > > >
> > > > > - Only access to the standard registers (0 through 31) is
> > supported.
> > > > > - Access to MMD address spaces other than MMD address space 1 is
> > > > > possible if the spd_clock_gate_override bit is set.
> > > > > - Access to MMD address space 1 is not possible.
> > > > >
> > > > > However, ksz9131_resume() calls ksz9131_config_rgmii_delay()
> > > > > before
> > > > > kszphy_resume() clears BMCR_PDOWN. This means MMD registers are
> > > > > accessed
> > > > while the PHY is still in SPD,
> > > > > contrary to the datasheet.
> > > >
> > > > SPD mode: This mode is used to power down the device when it is
> > > > not in use after power-up.
> > > > Previous register settings are maintained during and
> > > > following the removal of SPD.
> > > >
> > > > Suspend to Idle case, it is in SPD mode and the MMD register
> > > > values are retained.
> > > >
> > >
> > > On resume from s2idle, ksz9131_resume() calls
> > ksz9131_config_rgmii_delay() which does MMD accesses,
> > > while the PHY is in SPD. According to the datasheet, it shouldn't
> > happen. See commit e398822c4751
> > > ("net: phy: micrel: populate .soft_reset for KSZ9131") which fixes
> > > the
> > same issue.
> >
> > On my board, while s2idle in SPD mode, it does not hang. The datasheet
> > does not explain the behaviour when it is SPD mode. But it states that
> > it retains all previous register values when it is out of SPD mode.
> >
>
> According to the KSZ9131 datasheet ([1]):
>
> 4.17.3 SOFTWARE POWER-DOWN MODE (SPD)
> ...
> The following remain operational during SPD:
> MII Management Interface
> - Only access to the standard registers (0 through 31) is supported.
> - Access to MMD address spaces other than MMD address space 1 is
> possible if the spd_clock_gate_override bit is set.
> - Access to MMD address space 1 is not possible.
>
>
> The spd_clock_gate_override bit is not used in the KSZ9131 driver.
>
> While the datasheet does not specify exactly what happens if registers from an unsupported address
> space are accessed while the PHY is in SPD, I think it is correct for the driver to not do it in the
> first place.
>
> [1]
> https://ww1.microchip.com/downloads/aemDocuments/documents/UNG/ProductDocuments/DataSheets/00002841D.pd
> f
For s2idlecase: ie, PHY is in software power down state you don't need to restore
MMD register, as exiting software power down will restore those registers.
You need only restore MMD registers, when PHY loses power ie, suspend to RAM case.
Cheers,
Biju
^ permalink raw reply
* Re: [PATCH net] net: airoha: Fix memory leak in airoha_qdma_rx_process()
From: Simon Horman @ 2026-04-03 15:59 UTC (permalink / raw)
To: Lorenzo Bianconi
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260402-airoha_qdma_rx_process-mem-leak-fix-v1-1-b5706f402d3c@kernel.org>
On Thu, Apr 02, 2026 at 02:57:10PM +0200, Lorenzo Bianconi wrote:
> If an error occurs on the subsequents buffers belonging to the
> non-linear part of the skb (e.g. due to an error in the payload length
> reported by the NIC or if we consumed all the available fragments for
> the skb), the page_pool fragment will not be linked to the skb so it will
> not return to the pool in the airoha_qdma_rx_process() error path. Fix the
> memory leak partially reverting commit 'd6d2b0e1538d ("net: airoha: Fix
> page recycling in airoha_qdma_rx_process()")' and always running
> page_pool_put_full_page routine in the airoha_qdma_rx_process() error
> path.
>
> Fixes: d6d2b0e1538d ("net: airoha: Fix page recycling in airoha_qdma_rx_process()")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
^ 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