* Re: [PATCH] net: bnx2x: validate firmware section bounds without overflow
From: Andrew Lunn @ 2026-07-06 15:30 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Sudarsana Kalluru, Manish Chopra, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
In-Reply-To: <20260706093403.81017-1-pengpeng@iscas.ac.cn>
On Mon, Jul 06, 2026 at 05:34:03PM +0800, Pengpeng Hou wrote:
> The firmware loader validates each section with offset + length before it
> uses section offsets to read data from the firmware image. Both fields are
> 32-bit values from the firmware header, so the addition can wrap before it
> is compared with the firmware size.
>
> Validate sections as offset <= size and length <= size - offset instead.
> Also require the firmware version section to contain the four bytes that
> bnx2x_check_firmware() reads later.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Please stop posting patches. I gets very frustrating having to point
out again and again the same errors.
Please work on one patch. Make all the basic errors once, on one
patch, until you get it merged. Then post the next patch, hopefully
correctly.
Please reply to all your patches with:
pw-bot: cr
so that they get dropped from the review system, so they don't waste
our time.
Andrew
^ permalink raw reply
* Re: [PATCH v2 net 2/3] ipv6: mcast: Fix potential UAF in MLD delayed work
From: Ido Schimmel @ 2026-07-06 15:29 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
Kuniyuki Iwashima, David Ahern, netdev, eric.dumazet
In-Reply-To: <20260705181756.963063-3-edumazet@google.com>
On Sun, Jul 05, 2026 at 06:17:55PM +0000, Eric Dumazet wrote:
> A race condition exists between device teardown and incoming MLD query
> processing, leading to a Use-After-Free in the MLD delayed work.
>
> During device destruction, the primary reference to inet6_dev is dropped,
> which can drop its refcount to 0. The actual freeing of inet6_dev memory
> is deferred via RCU.
>
> Concurrently, the packet receive path runs under RCU read lock and obtains
> the inet6_dev pointer. Because the memory is RCU-protected, CPU-0 can
> safely dereference inet6_dev even if its refcount has hit 0.
>
> However, if CPU-0 calls igmp6_event_query() and schedules delayed work, it
> attempts to acquire a reference using in6_dev_hold(). This increments the
> refcount from 0 to 1, triggering a "refcount_t: addition on 0" warning.
> Since the inet6_dev memory is still scheduled to be freed after the RCU
> grace period, the device is freed while the work is still scheduled.
> When the work runs, it accesses the freed memory, causing a kernel panic.
>
> Fix this by using refcount_inc_not_zero() (via a new helper
> in6_dev_hold_safe()) to prevent acquiring a reference if the device is
> already being destroyed. If the refcount is 0, we do not schedule the work.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
^ permalink raw reply
* Re: [PATCH v2 net 1/3] ipv4: igmp: Fix potential UAF in igmp_gq_start_timer()
From: Ido Schimmel @ 2026-07-06 15:28 UTC (permalink / raw)
To: Eric Dumazet
Cc: David S . Miller, Jakub Kicinski, Paolo Abeni, Simon Horman,
Kuniyuki Iwashima, David Ahern, netdev, eric.dumazet,
Zero Day Initiative
In-Reply-To: <20260705181756.963063-2-edumazet@google.com>
On Sun, Jul 05, 2026 at 06:17:54PM +0000, Eric Dumazet wrote:
> A race condition exists between device teardown (inetdev_destroy) and
> incoming IGMP query processing (igmp_rcv), leading to a Use-After-Free
> in the IGMP timer callback.
>
> During device destruction, inetdev_destroy() drops the primary reference
> to in_device, which can drop its refcount to 0. The actual freeing of
> in_device memory is deferred via RCU (using call_rcu()).
>
> Concurrently, igmp_rcv() runs under RCU read lock and obtains the
> in_device pointer. Because the memory is RCU-protected, CPU-0 can safely
> dereference in_device even if its refcount has hit 0.
>
> However, if CPU-0 calls igmp_gq_start_timer() and re-arms the timer, it
> attempts to acquire a reference using in_dev_hold(). This increments the
> refcount from 0 to 1, triggering a "refcount_t: addition on 0" warning.
> Since the in_device memory is still scheduled to be freed after the RCU
> grace period (as the free callback does not check the refcount again),
> the device is freed while the timer is still armed. When the timer
> expires, it accesses the freed memory, causing a kernel panic.
>
> Fix this by using refcount_inc_not_zero() (via a new helper
> in_dev_hold_safe()) to prevent acquiring a reference if the device is
> already being destroyed. If the refcount is 0, we do not arm the timer.
>
> A similar issue in IPv6 MLD is fixed in a subsequent patch.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> Reported-by: Zero Day Initiative <zdi-disclosures@trendmicro.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: qt2025: Use vertical import style
From: Miguel Ojeda @ 2026-07-06 15:28 UTC (permalink / raw)
To: Gary Guo
Cc: Miguel Ojeda, Andrew Lunn, Guru Das Srinagesh, FUJITA Tomonori,
Trevor Gross, Heiner Kallweit, Russell King, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, netdev, rust-for-linux,
linux-kernel
In-Reply-To: <DJRKZD8LBXXH.MCISM5ZLNVMP@garyguo.net>
On Mon, Jul 6, 2026 at 5:16 PM Gary Guo <gary@garyguo.net> wrote:
>
> Miguel, do you think it's worth moving to Rust style edition 2024 before we
> switch the lang edition?
Maybe -- we could easily do it when we remove the `//` comments, i.e.
we could have a couple automated commits applied at once by Linus
before an -rc1.
Cheers,
Miguel
^ permalink raw reply
* Re: [PATCH bpf-next 2/6] bpf: Add ksock kfuncs
From: Mahe Tardy @ 2026-07-06 15:28 UTC (permalink / raw)
To: bot+bpf-ci
Cc: bpf, andrew+netdev, andrii, ast, daniel, davem, eddyz87, edumazet,
john.fastabend, kuba, liamwisehart, martin.lau, pabeni, song,
netdev, martin.lau, yonghong.song, clm, ihor.solodrai
In-Reply-To: <268078861c26e02c25e9e882bccc607bedf580ae3c1d7e06562c48b85450f1a7@mail.kernel.org>
On Mon, Jul 06, 2026 at 10:30:04AM +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/net/core/bpf_ksock.c b/net/core/bpf_ksock.c
> > new file mode 100644
> > index 000000000000..8bde734bc917
> > --- /dev/null
> > +++ b/net/core/bpf_ksock.c
>
> [ ... ]
>
> > @@ -0,0 +1,516 @@
>
> [ ... ]
>
> > +static int __init bpf_ksock_kfunc_init(void)
> > +{
> > + int ret;
> > + const struct btf_id_dtor_kfunc bpf_ksock_dtors[] = {
> > + {
> > + .btf_id = bpf_ksock_dtor_ids[0],
> > + .kfunc_btf_id = bpf_ksock_dtor_ids[1],
> > + },
> > + };
> > +
> > + ret = register_pernet_subsys(&bpf_ksock_net_ops);
> > + if (ret)
> > + return ret;
> > +
> > + ret = register_btf_kfunc_id_set(BPF_PROG_TYPE_SYSCALL,
> > + &ksock_init_kfunc_set);
> > + if (ret) {
> > + unregister_pernet_subsys(&bpf_ksock_net_ops);
> > + return ret;
> > + }
> > +
> > + ret = register_btf_kfunc_id_set(BPF_PROG_TYPE_SYSCALL,
> > + &ksock_kfunc_set);
> > + ret = ret ?: register_btf_kfunc_id_set(BPF_PROG_TYPE_LSM,
> > + &ksock_kfunc_set);
> > + return ret = ret ?: register_btf_id_dtor_kfuncs(bpf_ksock_dtors,
> > + ARRAY_SIZE(bpf_ksock_dtors),
> > + THIS_MODULE);
> ^^^^
>
> This isn't a bug, but in the final return statement the assignment
> to ret looks like a dead store since the value is returned right
> away. Could this just be:
>
> return ret ?: register_btf_id_dtor_kfuncs(bpf_ksock_dtors,
> ARRAY_SIZE(bpf_ksock_dtors),
> THIS_MODULE);
Indeed, this is relic of changes trying to get the cleanup part right,
see the other message from sashiko on the same patch.
>
> > +}
> > +
> > +late_initcall(bpf_ksock_kfunc_init);
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/28783010022
^ permalink raw reply
* Re: [Intel-wired-lan] [PATCH iwl-next v2] ixgbe: E610: force phy link to get down when interface is down
From: kernel test robot @ 2026-07-06 15:27 UTC (permalink / raw)
To: Jedrzej Jagielski, intel-wired-lan
Cc: llvm, oe-kbuild-all, anthony.l.nguyen, netdev, Jedrzej Jagielski,
Aleksandr Loktionov
In-Reply-To: <20260706094330.186341-1-jedrzej.jagielski@intel.com>
Hi Jedrzej,
kernel test robot noticed the following build errors:
[auto build test ERROR on tnguy-next-queue/dev-queue]
url: https://github.com/intel-lab-lkp/linux/commits/Jedrzej-Jagielski/ixgbe-E610-force-phy-link-to-get-down-when-interface-is-down/20260706-180351
base: https://git.kernel.org/pub/scm/linux/kernel/git/tnguy/next-queue.git dev-queue
patch link: https://lore.kernel.org/r/20260706094330.186341-1-jedrzej.jagielski%40intel.com
patch subject: [Intel-wired-lan] [PATCH iwl-next v2] ixgbe: E610: force phy link to get down when interface is down
config: x86_64-rhel-9.4-rust (https://download.01.org/0day-ci/archive/20260706/202607062312.8lqgVLms-lkp@intel.com/config)
compiler: clang version 22.1.3 (https://github.com/llvm/llvm-project e9846648fd6183ee6d8cbdb4502213fcf902a211)
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260706/202607062312.8lqgVLms-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202607062312.8lqgVLms-lkp@intel.com/
All errors (new ones prefixed by >>):
>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:7572:4: error: call to undeclared function 'e_error'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
7572 | e_error(drv, "Cannot set PHY link down\n");
| ^
>> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:7572:12: error: use of undeclared identifier 'drv'
7572 | e_error(drv, "Cannot set PHY link down\n");
| ^~~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8928:14: warning: division by zero is undefined [-Wdivision-by-zero]
8928 | cmd_type |= IXGBE_SET_FLAG(tx_flags, IXGBE_TX_FLAGS_HW_VLAN,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
8929 | IXGBE_ADVTXD_DCMD_VLE);
| ~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8918:26: note: expanded from macro 'IXGBE_SET_FLAG'
8918 | ((u32)(_input & _flag) / (_flag / _result)))
| ^ ~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8932:14: warning: division by zero is undefined [-Wdivision-by-zero]
8932 | cmd_type |= IXGBE_SET_FLAG(tx_flags, IXGBE_TX_FLAGS_TSO,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
8933 | IXGBE_ADVTXD_DCMD_TSE);
| ~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8918:26: note: expanded from macro 'IXGBE_SET_FLAG'
8918 | ((u32)(_input & _flag) / (_flag / _result)))
| ^ ~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8936:14: warning: division by zero is undefined [-Wdivision-by-zero]
8936 | cmd_type |= IXGBE_SET_FLAG(tx_flags, IXGBE_TX_FLAGS_TSTAMP,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
8937 | IXGBE_ADVTXD_MAC_TSTAMP);
| ~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8918:26: note: expanded from macro 'IXGBE_SET_FLAG'
8918 | ((u32)(_input & _flag) / (_flag / _result)))
| ^ ~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8940:14: warning: division by zero is undefined [-Wdivision-by-zero]
8940 | cmd_type ^= IXGBE_SET_FLAG(skb->no_fcs, 1, IXGBE_ADVTXD_DCMD_IFCS);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8918:26: note: expanded from macro 'IXGBE_SET_FLAG'
8918 | ((u32)(_input & _flag) / (_flag / _result)))
| ^ ~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8951:19: warning: division by zero is undefined [-Wdivision-by-zero]
8951 | olinfo_status |= IXGBE_SET_FLAG(tx_flags,
| ^~~~~~~~~~~~~~~~~~~~~~~~
8952 | IXGBE_TX_FLAGS_CSUM,
| ~~~~~~~~~~~~~~~~~~~~
8953 | IXGBE_ADVTXD_POPTS_TXSM);
| ~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8918:26: note: expanded from macro 'IXGBE_SET_FLAG'
8918 | ((u32)(_input & _flag) / (_flag / _result)))
| ^ ~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8956:19: warning: division by zero is undefined [-Wdivision-by-zero]
8956 | olinfo_status |= IXGBE_SET_FLAG(tx_flags,
| ^~~~~~~~~~~~~~~~~~~~~~~~
8957 | IXGBE_TX_FLAGS_IPV4,
| ~~~~~~~~~~~~~~~~~~~~
8958 | IXGBE_ADVTXD_POPTS_IXSM);
| ~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8918:26: note: expanded from macro 'IXGBE_SET_FLAG'
8918 | ((u32)(_input & _flag) / (_flag / _result)))
| ^ ~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8961:19: warning: division by zero is undefined [-Wdivision-by-zero]
8961 | olinfo_status |= IXGBE_SET_FLAG(tx_flags,
| ^~~~~~~~~~~~~~~~~~~~~~~~
8962 | IXGBE_TX_FLAGS_IPSEC,
| ~~~~~~~~~~~~~~~~~~~~~
8963 | IXGBE_ADVTXD_POPTS_IPSEC);
| ~~~~~~~~~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8918:26: note: expanded from macro 'IXGBE_SET_FLAG'
8918 | ((u32)(_input & _flag) / (_flag / _result)))
| ^ ~~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8969:19: warning: division by zero is undefined [-Wdivision-by-zero]
8969 | olinfo_status |= IXGBE_SET_FLAG(tx_flags,
| ^~~~~~~~~~~~~~~~~~~~~~~~
8970 | IXGBE_TX_FLAGS_CC,
| ~~~~~~~~~~~~~~~~~~
8971 | IXGBE_ADVTXD_CC);
| ~~~~~~~~~~~~~~~~
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c:8918:26: note: expanded from macro 'IXGBE_SET_FLAG'
8918 | ((u32)(_input & _flag) / (_flag / _result)))
| ^ ~~~~~~~~~~~~~~~~~
8 warnings and 2 errors generated.
vim +/e_error +7572 drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
7544
7545 /**
7546 * ixgbe_close - Disables a network interface
7547 * @netdev: network interface device structure
7548 *
7549 * Returns 0, this is not allowed to fail
7550 *
7551 * The close entry point is called when an interface is de-activated
7552 * by the OS. The hardware is still under the drivers control, but
7553 * needs to be disabled. A global MAC reset is issued to stop the
7554 * hardware, and all transmit and receive resources are freed.
7555 **/
7556 int ixgbe_close(struct net_device *netdev)
7557 {
7558 struct ixgbe_adapter *adapter = ixgbe_from_netdev(netdev);
7559
7560 ixgbe_ptp_stop(adapter);
7561
7562 if (netif_device_present(netdev))
7563 ixgbe_close_suspend(adapter);
7564
7565 ixgbe_fdir_filter_exit(adapter);
7566
7567 if (adapter->flags2 & IXGBE_FLAG2_LINK_DOWN_ON_CLOSE) {
7568 int err;
7569
7570 err = ixgbe_disable_phy_link(&adapter->hw);
7571 if (err)
> 7572 e_error(drv, "Cannot set PHY link down\n");
7573
7574 ixgbe_handle_link_down(adapter);
7575 }
7576
7577 ixgbe_release_hw_control(adapter);
7578
7579 return 0;
7580 }
7581
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH net-next v4] selftests/net/openvswitch: add ICMPv6 echo type match test
From: Aaron Conole @ 2026-07-06 15:27 UTC (permalink / raw)
To: Minxi Hou
Cc: netdev, echaudro, i.maximets, davem, edumazet, kuba, pabeni,
horms, shuah, dev, linux-kselftest
In-Reply-To: <20260702075044.1176798-1-houminxi@gmail.com>
Minxi Hou <houminxi@gmail.com> writes:
> Register OVS_KEY_ATTR_ICMPV6 in the flow key parser so that
> icmpv6(type=...) can be used in flow specifications. Without this
> registration the parser silently drops the token and the kernel
> rejects the flow with EINVAL because the expected ICMPv6 key
> attribute is missing.
>
> While here, add convert_int() to the ovs_key_ipv6 and ovs_key_icmp
> fields_map entries so that specifying a field value produces the
> correct wildcard mask. The IPv6 flow label uses convert_int(20) to
> produce a 20-bit mask (0x000FFFFF), matching the kernel constraint in
> flow_netlink.c that rejects masks with bits 20-31 set; byte-wide
> fields use convert_int(8). The ipv4 counterpart already does this via
> convert_int(); the ipv6 and icmp classes were simply missing the fifth
> tuple element. Existing callers that pass empty parentheses are
> unaffected because convert_int("") returns (0, 0).
>
> Add test_icmpv6 exercising the ICMPv6 echo flow key. The test uses
> static neighbour entries with nud permanent to prevent racy NDP, then
> verifies in three steps: install icmpv6(type=128) and
> icmpv6(type=129) flows and confirm ping works, remove the flows and
> confirm ping fails, reinstall and confirm recovery.
>
> Signed-off-by: Minxi Hou <houminxi@gmail.com>
> ---
Reviewed-by: Aaron Conole <aconole@redhat.com>
^ permalink raw reply
* Re: [PATCH bpf-next 3/6] selftests/bpf: Add ksock kfunc test
From: Mahe Tardy @ 2026-07-06 15:27 UTC (permalink / raw)
To: bot+bpf-ci
Cc: bpf, andrew+netdev, andrii, ast, daniel, davem, eddyz87, edumazet,
john.fastabend, kuba, liamwisehart, martin.lau, pabeni, song,
netdev, martin.lau, yonghong.song, clm, ihor.solodrai
In-Reply-To: <d49e2fcbde106e80971b769793170fd479315d563d31bcaf6db33737c01c814c@mail.kernel.org>
On Mon, Jul 06, 2026 at 10:16:33AM +0000, bot+bpf-ci@kernel.org wrote:
> > Add a selftest that exercises the ksock kfuncs end-to-end. One sycall
> > bpf setup program creates a ksock context and connect the socket.
> > Another syscall bpf program lookup the context and send test data.
> > The userspace harness create a network namespace and a new socket on
> > loopback, run the setup and send syscall bpf progs then check that the
> > userspace socket received the data from bpf.
>
> This isn't a bug, but would a quick pass over the changelog wording help
> here? A few spots read a little off:
>
> "One sycall" -> "One syscall"
> "creates a ksock context and connect the socket" -> connects
> "Another syscall bpf program lookup the context" -> looks up
> "The userspace harness create a network namespace" -> creates
Will fix these typos in next iteration.
>
>
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
>
> CI run summary: https://github.com/kernel-patches/bpf/actions/runs/28783010022
^ permalink raw reply
* Re: [PATCH] net: prestera: validate firmware header length
From: Andrew Lunn @ 2026-07-06 15:26 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Elad Nachman, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel
In-Reply-To: <20260706092602.79240-1-pengpeng@iscas.ac.cn>
On Mon, Jul 06, 2026 at 05:26:02PM +0800, Pengpeng Hou wrote:
> prestera_fw_hdr_parse() reads the firmware header before checking
> that the firmware image contains that header.
>
> Reject images shorter than struct prestera_fw_header before decoding the
> magic and version fields.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Please set the Subject: line correctly.
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH v2 5/5] ARM: dts: rockchip: Add Alientek DLRV1126
From: Andrew Lunn @ 2026-07-06 15:25 UTC (permalink / raw)
To: Yanan He
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue, Frank,
Heiner Kallweit, Russell King, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip, netdev, linux-stm32
In-Reply-To: <20260706-rv1126-alientek-dlrv1126-v2-5-ff3176ca362b@gmail.com>
> +&gmac {
> + phy-mode = "rgmii-id";
> + clock_in_out = "input";
> + assigned-clocks = <&cru CLK_GMAC_SRC>, <&cru CLK_GMAC_TX_RX>,
> + <&cru CLK_GMAC_ETHERNET_OUT>;
> + assigned-clock-parents = <&cru CLK_GMAC_SRC_M1>,
> + <&cru RGMII_MODE_CLK>;
> + assigned-clock-rates = <125000000>, <0>, <25000000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&rgmiim1_miim &rgmiim1_bus2 &rgmiim1_bus4
> + &clk_out_ethernetm1_pins>;
> + phy-handle = <&phy>;
> + status = "okay";
> +};
> +
> +&mdio {
> + phy: ethernet-phy@1 {
> + compatible = "ethernet-phy-ieee802.3-c22";
> + reg = <0x1>;
> + clocks = <&cru CLK_GMAC_ETHERNET_OUT>;
> + pinctrl-names = "default";
> + pinctrl-0 = <ð_phy_rst>;
> + reset-gpios = <&gpio3 RK_PA0 GPIO_ACTIVE_LOW>;
> + reset-assert-us = <20000>;
> + reset-deassert-us = <100000>;
> + };
> +};
For these nodes only:
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH] bonding: fix devconf_all NULL dereference when IPv6 is disabled
From: Andrew Lunn @ 2026-07-06 15:23 UTC (permalink / raw)
To: zhangzl2013
Cc: Jay Vosburgh, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Hangbin Liu, netdev, linux-kernel,
Qianheng Peng, Zhaolong Zhang
In-Reply-To: <20260706084530.447402-1-zhangzl2013@126.com>
On Mon, Jul 06, 2026 at 04:45:30PM +0800, zhangzl2013@126.com wrote:
> From: Zhaolong Zhang <zhangzl68@chinatelecom.cn>
>
> When booting with the 'ipv6.disable=1' parameter, the devconf_all is
> never initialized because inet6_init() exits before addrconf_init() is
> called which initializes it. bond_send_validate(), however, will still
> call bond_ns_send_all() even ipv6 is indeed disabled. It will lead to
> NULL derefence of net->ipv6.devconf_all in ip6_pol_route().
>
> BUG: kernel NULL pointer dereference, address: 000000000000000c
> [...]
> Workqueue: bond0 bond_arp_monitor [bonding]
> RIP: 0010:ip6_pol_route+0x69/0x480
> [...]
> Call Trace:
> <TASK>
> ? srso_return_thunk+0x5/0x5f
> ? __pfx_ip6_pol_route_output+0x10/0x10
> fib6_rule_lookup+0xfe/0x260
> ? wakeup_preempt+0x8a/0x90
> ? srso_return_thunk+0x5/0x5f
> ? srso_return_thunk+0x5/0x5f
> ? sched_balance_rq+0x369/0x810
> ip6_route_output_flags+0xd7/0x170
> bond_ns_send_all+0xde/0x280 [bonding]
> bond_ab_arp_probe+0x296/0x320 [bonding]
> ? srso_return_thunk+0x5/0x5f
> bond_activebackup_arp_mon+0xb4/0x2c0 [bonding]
> process_one_work+0x196/0x370
> worker_thread+0x1af/0x320
> ? srso_return_thunk+0x5/0x5f
> ? __pfx_worker_thread+0x10/0x10
> kthread+0xe3/0x120
> ? __pfx_kthread+0x10/0x10
> ret_from_fork+0x199/0x260
> ? __pfx_kthread+0x10/0x10
> ret_from_fork_asm+0x1a/0x30
> </TASK>
>
> Fix this by adding ipv6_mod_enabled() condition check in the caller.
>
> Fixes: 4e24be018eb9 ("bonding: add new parameter ns_targets")
> Signed-off-by: Qianheng Peng <pengqh1@chinatelecom.cn>
> Signed-off-by: Zhaolong Zhang <zhangzl68@chinatelecom.cn>
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
Please set the Subject: line correctly.
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net] net: stmmac: intel: don't reconfigure SerDes on unchanged mode
From: Andrew Lunn @ 2026-07-06 15:21 UTC (permalink / raw)
To: Markus Breitenberger
Cc: netdev, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Choong Yong Liang, stable,
Markus Breitenberger
In-Reply-To: <20260706061954.94842-1-bre@breiti.cc>
On Mon, Jul 06, 2026 at 08:19:54AM +0200, Markus Breitenberger wrote:
> From: Markus Breitenberger <bre@keba.com>
>
> intel_mac_finish() is registered as the phylink mac_finish() callback
> for the Elkhart Lake SGMII ports. phylink calls mac_finish() at the end
> of every major link reconfiguration, including the initial one during
> probe, before any interface mode has actually changed.
>
> The callback reprograms the shared ModPHY LCPLL through the PMC IPC and
> then power-cycles the SerDes. On Elkhart Lake that ModPHY is also used
> by the on-die AHCI SATA PHY. Running the reconfiguration during the
> initial boot-time link-up disturbs the shared analog block while it is
> still driving SATA, so the SATA link fails to train:
>
> ata1: SATA link down (SStatus 1 SControl 300)
>
> The disk carrying the root filesystem is never detected and the system
> hangs at rootwait. Ethernet itself comes up normally, which makes the
> failure look unrelated to the network driver.
>
> Firmware already programs the ModPHY for the configured interface, so
> the reconfiguration is redundant unless the interface mode really
> changes. Return early when the requested mode equals the current one.
> This avoids touching the shared ModPHY (and the SATA PHY) during boot
> while preserving runtime SGMII to 2500BASE-X switching, which still
> sees a genuine mode change and reconfigures as before.
What happens to the disk at runtime, rather than boot time, if it is
necessary to reconfigure the ModPHY?
I think i would prefer the machine fails to boot, rather than corrupt
its disk when i plug it into a different network switch.
Andrew
^ permalink raw reply
* Re: [PATCH] atm: solos-pci: validate DMA receive size
From: Andrew Lunn @ 2026-07-06 15:14 UTC (permalink / raw)
To: Pengpeng Hou; +Cc: Chas Williams, linux-atm-general, netdev, linux-kernel
In-Reply-To: <20260705084504.54281-1-pengpeng@iscas.ac.cn>
On Sun, Jul 05, 2026 at 04:45:04PM +0800, Pengpeng Hou wrote:
> The DMA receive path reads header->size from the RX buffer and uses it
> to extend the skb with skb_put(skb, size + sizeof(*header)). RX DMA skbs
> are allocated with RX_DMA_SIZE bytes, but the DMA path did not check
> that the device-provided size fits in that buffer. The MMIO path already
> has a similar size check against card->buffer_size.
>
> Reject an oversized DMA receive item before skb_put() and drop the
> invalid skb, then continue through the normal DMA RX refill path so the
> port is not left without a replacement receive buffer.
Subject: line
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH net] ieee802154: hwsim: free PIB after unregistering hardware
From: Miquel Raynal @ 2026-07-06 15:10 UTC (permalink / raw)
To: Yousef Alhouseen
Cc: alex.aring, stefan, andrew+netdev, davem, edumazet, kuba, pabeni,
linux-wpan, netdev, linux-kernel, stable,
syzbot+4707bb8a43a42fca2b97
In-Reply-To: <CAMuQ4bWf+o_ZDMXn1tTw30veo-30Mt9XZehT8BPErJ30Kx_95A@mail.gmail.com>
Hello Yousef,
On 03/07/2026 at 04:19:42 -07, Yousef Alhouseen <alhouseenyousef@gmail.com> wrote:
> Hello Miquel,
>
> After ieee802154_unregister_hw() returns, the driver callbacks that
> can replace phy->pib have been quiesced, and hwsim_del() has exclusive
> ownership of the final teardown. The pointer is no longer being
> fetched inside an RCU read-side critical section, so rcu_dereference()
> is not appropriate there.
That's right.
> rcu_dereference_protected(phy->pib, 1) expresses that there can no
> longer be a concurrent updater at that point; the protection condition
> is the completed unregister rather than a locally held lock. The value
> is only fetched so the final object can be passed to kfree_rcu().
While I believe this is indeed true, it actually feels slightly overkill
since there is no updater anymore and, as far as I understand, the only
thing that we need here is to get the pointer value for freeing, right?
> rcu_access_pointer() would also be sufficient for that limited use if
> you prefer it, and I can use that spelling in a v2.
If you don't mind, I feel like rcu_access_pointer() is exactly what we
need here. It is also more understandable, even though I agree in
practice there are no differences in this case.
Thanks,
Miquèl
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: phy: qt2025: Use vertical import style
From: Gary Guo @ 2026-07-06 15:07 UTC (permalink / raw)
To: Miguel Ojeda, Andrew Lunn, Guru Das Srinagesh
Cc: FUJITA Tomonori, Trevor Gross, Heiner Kallweit, Russell King,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
netdev, rust-for-linux, linux-kernel
In-Reply-To: <d2c1e11e-e616-4b2f-aa17-5eb96f045833@lunn.ch>
On Mon Jul 6, 2026 at 2:58 PM BST, Andrew Lunn wrote:
> On Sun, Jul 05, 2026 at 10:38:41PM -0700, Guru Das Srinagesh wrote:
>> Convert `use` imports to vertical layout for better readability and
>> maintainability.
>>
>> Signed-off-by: Guru Das Srinagesh <linux@gurudas.dev>
>> ---
>> drivers/net/phy/qt2025.rs | 10 ++++++++--
>> 1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/phy/qt2025.rs b/drivers/net/phy/qt2025.rs
>> index 470d89a0ac00..efde3f909367 100644
>> --- a/drivers/net/phy/qt2025.rs
>> +++ b/drivers/net/phy/qt2025.rs
>> @@ -14,11 +14,17 @@
>> use kernel::io::poll::read_poll_timeout;
>> use kernel::net::phy::{
>> self,
>> - reg::{Mmd, C45},
>> + reg::{
>> + Mmd,
>> + C45, //
>> + },
>
> Given the comment this should be sorted in 'ASCIIbetical order',
> isn't this wrong, C comes before M?
>
> Andrew
This is one of the quirks of rustfmt. Before style edition 2024, if an
identifier is all caps, it sorts it after non-all-caps identifiers. The
motivation was to ensure constants are ordered after types, however for things
like C45 it is actually a type, causing this weirdness.
Miguel, do you think it's worth moving to Rust style edition 2024 before we
switch the lang edition?
Best,
Gary
^ permalink raw reply
* Re: [PATCH] net: usb: sr9700: validate receive packet extent
From: Andrew Lunn @ 2026-07-06 15:07 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Ethan Nelson-Moore, Peter Korsgaard, Simon Horman,
linux-usb, netdev, linux-kernel
In-Reply-To: <20260705083724.24494-1-pengpeng@iscas.ac.cn>
On Sun, Jul 05, 2026 at 04:37:24PM +0800, Pengpeng Hou wrote:
> sr9700_rx_fixup() copies len bytes from skb->data + SR_RX_OVERHEAD when
> a URB contains multiple packets. The old check compared len against
> skb->len, but the source pointer has already skipped SR_RX_OVERHEAD
> bytes.
>
> Validate len against the remaining bytes after SR_RX_OVERHEAD before the
> copy and cursor advance.
Please fix the Subject: line.
Andrew
---
pw-bot: cr
^ permalink raw reply
* Re: [PATCH] net: usb: cx82310_eth: bound partial receive continuation
From: Andrew Lunn @ 2026-07-06 15:06 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Kees Cook, linux-usb, netdev, linux-kernel
In-Reply-To: <20260705083609.23977-1-pengpeng@iscas.ac.cn>
On Sun, Jul 05, 2026 at 04:36:09PM +0800, Pengpeng Hou wrote:
> cx82310_rx_fixup() completes a packet that started in the previous URB
> by copying dev->partial_rem bytes from the current skb. It then pulls
> the same continuation extent, rounded up to an even byte count. The code
> does not first prove that the current skb contains that continuation.
>
> Add a fail-closed bound check before the copy and pull. If the
> continuation is shorter than the pending packet state expects, drop that
> pending partial packet before returning so later URBs are not consumed as
> stale continuation bytes. This keeps the existing cross-URB packet
> model, but avoids consuming bytes that are not present in the current
> skb.
Please take a read of:
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
The Subject: line is wrong.
How has this been tested?
> static int cx82310_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
> {
> - int len;
> + int len, pull_len;
> struct sk_buff *skb2;
> struct cx82310_priv *priv = dev->driver_priv;
Although the reverse christmas tree is already broken here, you should
try to keep with it, and put the new line at the end.
>
> @@ -251,6 +251,13 @@
> * end of that packet at the beginning.
> */
> if (dev->partial_rem) {
> + pull_len = (dev->partial_rem + 1) & ~1;
> + if (skb->len < pull_len) {
> + dev->partial_len = 0;
> + dev->partial_rem = 0;
> + return 0;
> + }
> +
> len = dev->partial_len + dev->partial_rem;
> skb2 = alloc_skb(len, GFP_ATOMIC);
> if (!skb2)
> @@ -261,7 +265,7 @@
> memcpy(skb2->data + dev->partial_len, skb->data,
> dev->partial_rem);
> usbnet_skb_return(dev, skb2);
> - skb_pull(skb, (dev->partial_rem + 1) & ~1);
> + skb_pull(skb, pull_len);
> dev->partial_rem = 0;
> if (skb->len < 2)
> return 1;
>
^ permalink raw reply
* Re: [PATCH net 2/2] net: macb: mask TXUBR during TX NAPI poll to prevent IRQ storms
From: Sebastian Andrzej Siewior @ 2026-07-06 15:05 UTC (permalink / raw)
To: christian.taedcke
Cc: christian.taedcke-oss, Théo Lebrun, Conor Dooley,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Kevin Hao, Simon Horman, Clark Williams,
Steven Rostedt, Robert Hancock, netdev, linux-kernel,
linux-rt-devel, stable
In-Reply-To: <20260706-upstreaming-macb-irq-storm-v1-2-ab3115b5a13a@weidmueller.com>
On 2026-07-06 16:02:15 [+0200], Christian Taedcke via B4 Relay wrote:
> From: Christian Taedcke <christian.taedcke@weidmueller.com>
>
> macb_interrupt() defers TX completion handling to NAPI, but when it
> schedules the poll it only masks TCOMP, even though TXUBR is enabled
> alongside it (both are part of MACB_TX_INT_FLAGS). macb_tx_poll() is
> asymmetric in the same way and only re-enables TCOMP. TXUBR is thus
> left unmasked while responsibility for handling it has been deferred
> to NAPI.
So this is not a race condition, this is always a failure?
Sebastian
^ permalink raw reply
* Re: [PATCH net 1/2] net: macb: reprogram TBQP after shuffling the TX ring on link-up
From: Sebastian Andrzej Siewior @ 2026-07-06 15:04 UTC (permalink / raw)
To: christian.taedcke
Cc: christian.taedcke-oss, Théo Lebrun, Conor Dooley,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Kevin Hao, Simon Horman, Clark Williams,
Steven Rostedt, Robert Hancock, netdev, linux-kernel,
linux-rt-devel, stable
In-Reply-To: <20260706-upstreaming-macb-irq-storm-v1-1-ab3115b5a13a@weidmueller.com>
On 2026-07-06 16:02:14 [+0200], Christian Taedcke via B4 Relay wrote:
> From: Christian Taedcke <christian.taedcke@weidmueller.com>
>
> gem_shuffle_tx_one_ring() rotates the software TX ring so that the
> tail sits at index 0 and resets queue->tx_tail to 0, but it never
> reprograms the hardware transmit buffer queue pointer (TBQP). Other
> paths that reset tx_tail to the ring base (macb_init_buffers() and
> macb_tx_error_task()) also reprogram TBQP to queue->tx_ring_dma; this
> path does not, leaving TBQP pointing at a stale descriptor.
>
> gem_shuffle_tx_rings() runs on every link-up from
> macb_mac_link_up(). After a few link up/down flaps that leave
> un-completed descriptors in the ring, the stale TBQP keeps pointing at
> a descriptor whose used bit is set. When TX is re-enabled on link-up,
> the GEM reads that used descriptor and raises TXUBR. macb_interrupt()
> schedules the TX NAPI, macb_tx_poll() makes no progress (work_done ==
> 0) and macb_tx_restart() re-issues TSTART, which makes the controller
> read the same used descriptor again and re-assert TXUBR. As the MAC
> interrupt is level-triggered, it never deasserts and one CPU is pegged
> at 100% in the threaded handler, eventually triggering "sched: RT
> throttling activated" and a dead network interface.
But this should also happen with !RT at which point the interrupt runs
at 100% CPU and the softirq has hardly an chance to make progress, no?
> Fix it by reprogramming TBQP to the ring base on every path of
> gem_shuffle_tx_one_ring() that resets tx_tail to 0, mirroring
> macb_tx_error_task(). The early return for an already-aligned tail is
> left untouched as TBQP is already consistent there. This is safe
> because the shuffle runs from macb_mac_link_up() while TE is still
> disabled, so the transmitter is halted.
>
> Fixes: 881a0263d502 ("net: macb: Shuffle the tx ring before enabling tx")
This is v7.0-rc4. So that RT tree of yours has some backports or did you
run into this while trying to reproduce it upstream?
> Cc: stable@vger.kernel.org
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Christian Taedcke <christian.taedcke@weidmueller.com>
> ---
> drivers/net/ethernet/cadence/macb_main.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/cadence/macb_main.c b/drivers/net/ethernet/cadence/macb_main.c
> index fd282a1700fb..b11cb8f068b7 100644
> --- a/drivers/net/ethernet/cadence/macb_main.c
> +++ b/drivers/net/ethernet/cadence/macb_main.c
> @@ -820,7 +820,7 @@ static void gem_shuffle_tx_one_ring(struct macb_queue *queue)
> if (!count) {
> queue->tx_head = 0;
> queue->tx_tail = 0;
> - goto unlock;
> + goto reset_hw_ptr;
This update is even needed for count == 0 case? I kind of do understand
that you need to updated if you shuffled the descriptors around.
> }
>
> shift = tail % ring_size;
> @@ -869,6 +869,13 @@ static void gem_shuffle_tx_one_ring(struct macb_queue *queue)
> /* Make descriptor updates visible to hardware */
> wmb();
>
> +reset_hw_ptr:
> + /* tx_tail was reset to the ring base, so TBQP must be reprogrammed
> + * to match; otherwise it keeps pointing at a stale descriptor. Safe
> + * to write directly here as TX is still disabled (called from
> + * macb_mac_link_up() before TE is set).
> + */
> + queue_writel(queue, TBQP, lower_32_bits(queue->tx_ring_dma));
> unlock:
> spin_unlock_irqrestore(&queue->tx_ptr_lock, flags);
> }
>
Sebastian
^ permalink raw reply
* [PATCH net v4 3/3] octeon_ep_vf: fix skb frags overflow in the RX path
From: Maoyi Xie @ 2026-07-06 15:02 UTC (permalink / raw)
To: Veerasenareddy Burru, Sathesh Edara, Satananda Burla,
Shinas Rasheed
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maciej Fijalkowski, Guangshuo Li, David Carlier,
netdev, linux-kernel
In-Reply-To: <20260706150208.2944898-1-maoyixie.tju@gmail.com>
__octep_vf_oq_process_rx() has the same unbounded fragment loop as the PF
driver. buff_info->len comes from the device response header. The loop adds
one fragment per buffer_size chunk with no check against MAX_SKB_FRAGS. A
long packet yields about 18 fragments. That is one past the default
MAX_SKB_FRAGS of 17. skb_add_rx_frag() then writes past shinfo->frags[].
The fragment count is now checked before napi_build_skb(). A packet that
needs more fragments than the skb can hold is dropped.
octep_vf_oq_drop_rx() drains those descriptors. It also frees the head page
and every fragment page. The previous patch added those frees to the inline
drop path. The napi_build_skb() failure path now uses the same helper.
Fixes: 1cd3b407977c ("octeon_ep_vf: add Tx/Rx processing and interrupt support")
Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
---
.../marvell/octeon_ep_vf/octep_vf_rx.c | 50 ++++++++++++-------
1 file changed, 32 insertions(+), 18 deletions(-)
diff --git a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
index 302559b16b..e7733b41a1 100644
--- a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
+++ b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
@@ -357,6 +357,31 @@ static inline u32 octep_vf_oq_next_idx(struct octep_vf_oq *oq, u32 idx)
return (idx + 1 == oq->max_count) ? 0 : idx + 1;
}
+static void octep_vf_oq_drop_rx(struct octep_vf_oq *oq,
+ struct octep_vf_rx_buffer *buff_info,
+ void *resp_hw, u32 *read_idx, u32 *desc_used)
+{
+ u16 data_len = buff_info->len - oq->max_single_buffer_size;
+
+ put_page(virt_to_page(resp_hw));
+ (*desc_used)++;
+ *read_idx = octep_vf_oq_next_idx(oq, *read_idx);
+ while (data_len) {
+ dma_unmap_page(oq->dev, oq->desc_ring[*read_idx].buffer_ptr,
+ PAGE_SIZE, DMA_FROM_DEVICE);
+ buff_info = (struct octep_vf_rx_buffer *)
+ &oq->buff_info[*read_idx];
+ put_page(buff_info->page);
+ buff_info->page = NULL;
+ if (data_len < oq->buffer_size)
+ data_len = 0;
+ else
+ data_len -= oq->buffer_size;
+ (*desc_used)++;
+ *read_idx = octep_vf_oq_next_idx(oq, *read_idx);
+ }
+}
+
/**
* __octep_vf_oq_process_rx() - Process hardware Rx queue and push to stack.
*
@@ -432,27 +457,16 @@ static int __octep_vf_oq_process_rx(struct octep_vf_device *oct,
struct skb_shared_info *shinfo;
u16 data_len;
+ data_len = buff_info->len - oq->max_single_buffer_size;
+ if (DIV_ROUND_UP(data_len, oq->buffer_size) > MAX_SKB_FRAGS) {
+ octep_vf_oq_drop_rx(oq, buff_info, resp_hw, &read_idx, &desc_used);
+ continue;
+ }
+
skb = napi_build_skb((void *)resp_hw, PAGE_SIZE);
if (!skb) {
oq->stats->alloc_failures++;
- put_page(virt_to_page(resp_hw));
- desc_used++;
- read_idx = octep_vf_oq_next_idx(oq, read_idx);
- data_len = buff_info->len - oq->max_single_buffer_size;
- while (data_len) {
- dma_unmap_page(oq->dev, oq->desc_ring[read_idx].buffer_ptr,
- PAGE_SIZE, DMA_FROM_DEVICE);
- buff_info = (struct octep_vf_rx_buffer *)
- &oq->buff_info[read_idx];
- put_page(buff_info->page);
- buff_info->page = NULL;
- if (data_len < oq->buffer_size)
- data_len = 0;
- else
- data_len -= oq->buffer_size;
- desc_used++;
- read_idx = octep_vf_oq_next_idx(oq, read_idx);
- }
+ octep_vf_oq_drop_rx(oq, buff_info, resp_hw, &read_idx, &desc_used);
continue;
}
rx_bytes += buff_info->len;
--
2.34.1
^ permalink raw reply related
* [PATCH net v4 2/3] octeon_ep_vf: Fix RX page leak on napi_build_skb() failure
From: Maoyi Xie @ 2026-07-06 15:02 UTC (permalink / raw)
To: Veerasenareddy Burru, Sathesh Edara, Satananda Burla,
Shinas Rasheed
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maciej Fijalkowski, Guangshuo Li, David Carlier,
netdev, linux-kernel
In-Reply-To: <20260706150208.2944898-1-maoyixie.tju@gmail.com>
From: Guangshuo Li <lgs201920130244@gmail.com>
__octep_vf_oq_process_rx() clears buff_info->page before building an skb
from the RX page. On the success path the page is consumed by the skb,
either as the skb head or as an RX fragment.
If napi_build_skb() fails, however, the page is not consumed by an skb.
The error path advances the descriptor and leaves the ring slot cleared,
so the page is no longer tracked and is leaked. In the multi-fragment
case, the remaining fragment pages are also unmapped and removed from
their ring slots without being released.
Release the head page when napi_build_skb() fails, and release each
remaining fragment page before clearing its ring slot.
Fixes: dd66b4285470 ("octeon_ep_vf: add NULL check for napi_build_skb()")
Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com>
---
drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
index d982474082..302559b16b 100644
--- a/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
+++ b/drivers/net/ethernet/marvell/octeon_ep_vf/octep_vf_rx.c
@@ -418,6 +418,7 @@ static int __octep_vf_oq_process_rx(struct octep_vf_device *oct,
skb = napi_build_skb((void *)resp_hw, PAGE_SIZE);
if (!skb) {
oq->stats->alloc_failures++;
+ put_page(virt_to_page(resp_hw));
desc_used++;
read_idx = octep_vf_oq_next_idx(oq, read_idx);
continue;
@@ -434,6 +435,7 @@ static int __octep_vf_oq_process_rx(struct octep_vf_device *oct,
skb = napi_build_skb((void *)resp_hw, PAGE_SIZE);
if (!skb) {
oq->stats->alloc_failures++;
+ put_page(virt_to_page(resp_hw));
desc_used++;
read_idx = octep_vf_oq_next_idx(oq, read_idx);
data_len = buff_info->len - oq->max_single_buffer_size;
@@ -442,6 +444,7 @@ static int __octep_vf_oq_process_rx(struct octep_vf_device *oct,
PAGE_SIZE, DMA_FROM_DEVICE);
buff_info = (struct octep_vf_rx_buffer *)
&oq->buff_info[read_idx];
+ put_page(buff_info->page);
buff_info->page = NULL;
if (data_len < oq->buffer_size)
data_len = 0;
--
2.34.1
^ permalink raw reply related
* [PATCH net v4 1/3] octeon_ep: fix skb frags overflow in the RX path
From: Maoyi Xie @ 2026-07-06 15:02 UTC (permalink / raw)
To: Veerasenareddy Burru, Sathesh Edara, Satananda Burla,
Shinas Rasheed
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maciej Fijalkowski, Guangshuo Li, David Carlier,
netdev, linux-kernel
In-Reply-To: <20260706150208.2944898-1-maoyixie.tju@gmail.com>
__octep_oq_process_rx() builds an skb for a multi-buffer packet by adding
one fragment per buffer_size chunk:
data_len = buff_info->len - oq->max_single_buffer_size;
while (data_len) {
...
skb_add_rx_frag(skb, shinfo->nr_frags, buff_info->page, 0,
buff_info->len, buff_info->len);
...
}
buff_info->len comes from the device response header
(be64_to_cpu(resp_hw->length)). Nothing bounds the fragment count against
MAX_SKB_FRAGS. data_len can be close to 65535. buffer_size defaults to
about 3776 on 4K pages, so a full packet yields about 18 fragments. That
is one more than the default MAX_SKB_FRAGS of 17, so skb_add_rx_frag()
writes past shinfo->frags[].
The fragment count is now checked before build_skb(). A packet that needs
more fragments than the skb can hold is dropped. octep_oq_drop_rx()
consumes its descriptors like the build_skb failure path. The same class
was fixed in other RX paths, including commit 5ffcb7b890f6 ("net: atlantic:
fix fragment overflow handling in RX path") and commit f0813bcd2d9d ("net:
wwan: t7xx: fix potential skb->frags overflow in RX path").
Fixes: 37d79d059606 ("octeon_ep: add Tx/Rx processing and interrupt support")
Co-developed-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Kaixuan Li <kaixuan.li@ntu.edu.sg>
Signed-off-by: Maoyi Xie <maoyixie.tju@gmail.com>
Reviewed-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
---
drivers/net/ethernet/marvell/octeon_ep/octep_rx.c | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c b/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
index e6ebc7e44a..bdbed58c7b 100644
--- a/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
+++ b/drivers/net/ethernet/marvell/octeon_ep/octep_rx.c
@@ -453,6 +453,15 @@ static int __octep_oq_process_rx(struct octep_device *oct,
octep_oq_next_pkt(oq, buff_info, &read_idx, &desc_used);
+ if (buff_info->len > oq->max_single_buffer_size) {
+ u16 data_len = buff_info->len - oq->max_single_buffer_size;
+
+ if (DIV_ROUND_UP(data_len, oq->buffer_size) > MAX_SKB_FRAGS) {
+ octep_oq_drop_rx(oq, buff_info, &read_idx, &desc_used);
+ continue;
+ }
+ }
+
skb = build_skb((void *)resp_hw, PAGE_SIZE);
if (!skb) {
octep_oq_drop_rx(oq, buff_info,
--
2.34.1
^ permalink raw reply related
* [PATCH net v4 0/3] octeon_ep, octeon_ep_vf: fix RX skb frags overflow and page leak
From: Maoyi Xie @ 2026-07-06 15:02 UTC (permalink / raw)
To: Veerasenareddy Burru, Sathesh Edara, Satananda Burla,
Shinas Rasheed
Cc: Andrew Lunn, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Maciej Fijalkowski, Guangshuo Li, David Carlier,
netdev, linux-kernel
The octeon_ep and octeon_ep_vf RX paths add one skb fragment per buffer
with no bound against MAX_SKB_FRAGS. buff_info->len comes from the device
response header. A long packet needs about 18 fragments. That is one past
the default MAX_SKB_FRAGS of 17, so skb_add_rx_frag() writes past
shinfo->frags[]. Patch 1 bounds octeon_ep. Patch 3 bounds octeon_ep_vf.
Patch 2 is Guangshuo Li's fix for an octeon_ep_vf RX page leak on the
napi_build_skb() failure path. It touches the same drop code as patch 3.
I carry it here so the series applies without conflict, per Maciej. Patch 3
moves that drain loop into a helper. The helper carries the page frees from
patch 2, so the overflow drop path frees its pages too.
octeon_ep has the same leak on its drop path. A separate patch will fix it
once this series lands.
v4:
- add Guangshuo Li's octeon_ep_vf page leak fix as patch 2, per Maciej.
- octeon_ep_vf: the fragment count fix now sits on top of patch 2. The drop
helper octep_vf_oq_drop_rx() frees the head and fragment pages.
- octeon_ep: no change, keeps Maciej's Reviewed-by.
v1: https://lore.kernel.org/r/20260701112825.1653044-1-maoyixie.tju@gmail.com
v2: https://lore.kernel.org/r/20260702180518.2013324-1-maoyixie.tju@gmail.com
v3: https://lore.kernel.org/r/20260704061511.2350737-1-maoyixie.tju@gmail.com
Guangshuo Li (1):
octeon_ep_vf: Fix RX page leak on napi_build_skb() failure
Maoyi Xie (2):
octeon_ep: fix skb frags overflow in the RX path
octeon_ep_vf: fix skb frags overflow in the RX path
.../net/ethernet/marvell/octeon_ep/octep_rx.c | 9 ++++
.../marvell/octeon_ep_vf/octep_vf_rx.c | 49 +++++++++++++------
2 files changed, 42 insertions(+), 16 deletions(-)
--
2.34.1
^ permalink raw reply
* Re: [PATCH v2 3/5] net: phy: motorcomm: Enable optional clock for YT8531
From: Andrew Lunn @ 2026-07-06 14:57 UTC (permalink / raw)
To: Yanan He
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue, Frank,
Heiner Kallweit, Russell King, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip, netdev, linux-stm32
In-Reply-To: <20260706-rv1126-alientek-dlrv1126-v2-3-ff3176ca362b@gmail.com>
On Mon, Jul 06, 2026 at 05:14:43PM +0800, Yanan He wrote:
> Some boards feed the YT8531 PHY from an SoC-provided external
> reference clock described by the common ethernet-phy "clocks" property.
>
> Enable the optional PHY clock during probe so boards can model this
> clock as a PHY input instead of keeping the clock alive from the MAC
> driver.
>
> This is needed on the Alientek DLRV1126, where the PHY reference clock
> is provided by CLK_GMAC_ETHERNET_OUT.
>
> Signed-off-by: Yanan He <grumpycat921013@gmail.com>
Please separate this out and post to netdev.
https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html
Andrew
^ permalink raw reply
* Re: [PATCH v2 3/5] net: phy: motorcomm: Enable optional clock for YT8531
From: Andrew Lunn @ 2026-07-06 14:56 UTC (permalink / raw)
To: Yanan He
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, David Wu, Maxime Coquelin, Alexandre Torgue, Frank,
Heiner Kallweit, Russell King, devicetree, linux-kernel,
linux-arm-kernel, linux-rockchip, netdev, linux-stm32
In-Reply-To: <20260706-rv1126-alientek-dlrv1126-v2-3-ff3176ca362b@gmail.com>
On Mon, Jul 06, 2026 at 05:14:43PM +0800, Yanan He wrote:
> Some boards feed the YT8531 PHY from an SoC-provided external
> reference clock described by the common ethernet-phy "clocks" property.
>
> Enable the optional PHY clock during probe so boards can model this
> clock as a PHY input instead of keeping the clock alive from the MAC
> driver.
>
> This is needed on the Alientek DLRV1126, where the PHY reference clock
> is provided by CLK_GMAC_ETHERNET_OUT.
>
> Signed-off-by: Yanan He <grumpycat921013@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ 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