* Re: [PATCH net-next v2] ice: use dev_err_probe() in ice_probe()
From: weirongguang @ 2026-07-02 7:05 UTC (permalink / raw)
To: Maciej Fijalkowski, Rongguang Wei
Cc: netdev, intel-wired-lan, aleksandr.loktionov, przemyslaw.kitszel,
anthony.l.nguyen, andrew+netdev
In-Reply-To: <akUmFsLra3VpRNPg@boxer>
在 2026/7/1 22:37, Maciej Fijalkowski 写道:
> On Wed, Jul 01, 2026 at 09:36:18AM +0800, Rongguang Wei wrote:
>> From: Rongguang Wei <weirongguang@kylinos.cn>
>>
>> dev_err_probe() logs the error and returns the supplied error code, which
>> allows probe error paths to be written more compactly.
>>
>> Use dev_err_probe() in ice_probe() for error paths that currently print an
>> error message and immediately return the same error code. This keeps the
>> existing error handling semantics while reducing open-coded logging and
>> return sequences.
>>
>> Signed-off-by: Rongguang Wei <weirongguang@kylinos.cn>
>> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
>> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
>> ---
>> v2:
>> - Fix commit message per Aleksandr Loktionov's recommendation.
>> v1: https://lore.kernel.org/netdev/20260630032537.42605-1-clementwei90@163.com/T/#t
>> ---
>> drivers/net/ethernet/intel/ice/ice_main.c | 24 ++++++++---------------
>> 1 file changed, 8 insertions(+), 16 deletions(-)
>
> Could we also address rest of sites within driver at this very same
> commit?
>
> drivers/net/ethernet/intel/ice/ice_dcb_lib.c-873- dev_err(dev, "DCB init failed\n");
> drivers/net/ethernet/intel/ice/ice_dcb_lib.c:874: return err;
> --
> drivers/net/ethernet/intel/ice/ice_main.c-4482- dev_warn(dev, "Failed to initialize hardware after applying Tx scheduling configuration.\n");
> drivers/net/ethernet/intel/ice/ice_main.c:4483: return err;
> --
> drivers/net/ethernet/intel/ice/ice_main.c-4543- dev_err(dev, "Fail during requesting FW: %d\n", err);
> drivers/net/ethernet/intel/ice/ice_main.c:4544: return err;
> --
> drivers/net/ethernet/intel/ice/ice_main.c-4961- dev_err(dev, "ice_init_pf failed: %d\n", err);
> drivers/net/ethernet/intel/ice/ice_main.c:4962: return err;
> --
> drivers/net/ethernet/intel/ice/ice_main.c-5192- dev_err(dev, "BAR0 I/O map error %d\n", err);
> drivers/net/ethernet/intel/ice/ice_main.c:5193: return err;
> --
> drivers/net/ethernet/intel/ice/ice_main.c-5206- dev_err(dev, "DMA configuration failed: 0x%x\n", err);
> drivers/net/ethernet/intel/ice/ice_main.c:5207: return err;
> --
> drivers/net/ethernet/intel/ice/ice_main.c-5244- dev_err(dev, "ice_init_hw failed: %d\n", err);
> drivers/net/ethernet/intel/ice/ice_main.c:5245: return err;
> --
> drivers/net/ethernet/intel/ice/ice_main.c-9627- netdev_err(netdev, "Failed to get link info, error %d\n", err);
> drivers/net/ethernet/intel/ice/ice_main.c:9628: return err;
> --
> drivers/net/ethernet/intel/ice/devlink/devlink.c-1244- dev_err(dev, "ice_init_hw failed: %d\n", err);
> drivers/net/ethernet/intel/ice/devlink/devlink.c:1245: return err;
> --
> drivers/net/ethernet/intel/ice/ice_ptp.c-1935- dev_err(ice_pf_to_dev(pf), "PTP failed to set time %d\n", err);
> drivers/net/ethernet/intel/ice/ice_ptp.c:1936: return err;
> --
> drivers/net/ethernet/intel/ice/ice_ptp.c-2000- dev_err(dev, "PTP failed to adjust time, err %d\n", err);
> drivers/net/ethernet/intel/ice/ice_ptp.c:2001: return err;
> --
> drivers/net/ethernet/intel/ice/ice_sriov.c-829- dev_err(dev, "Failed to enable SR-IOV: %d\n", err);
> drivers/net/ethernet/intel/ice/ice_sriov.c:830: return err;
> --
> drivers/net/ethernet/intel/ice/ice_eswitch_br.c-314- dev_info(dev, "Bridge port lookup failed (vsi=%u)\n", vsi_idx);
> drivers/net/ethernet/intel/ice/ice_eswitch_br.c:315: return ERR_PTR(-EINVAL);
>
Hi,
Per commit a787e5400a1c("driver core: add device probe log helper"), dev_err_probe was
originally designed for probe functions in device driver to handle -EPROBE_DEFER.
Using it elsewhere is not the common pattern in the kernel. I'm unsure whether this aligns
with the intended usage if we also address the rest of the sites within the driver.
>>
>> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
>> index e2fd2dab03e3..31aa42f8e6d3 100644
>> --- a/drivers/net/ethernet/intel/ice/ice_main.c
>> +++ b/drivers/net/ethernet/intel/ice/ice_main.c
>> @@ -5161,10 +5161,8 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
>> struct ice_hw *hw;
>> int err;
>>
>> - if (pdev->is_virtfn) {
>> - dev_err(dev, "can't probe a virtual function\n");
>> - return -EINVAL;
>> - }
>> + if (pdev->is_virtfn)
>> + return dev_err_probe(dev, -EINVAL, "can't probe a virtual function\n");
>>
>> /* when under a kdump kernel initiate a reset before enabling the
>> * device in order to clear out any pending DMA transactions. These
>> @@ -5188,10 +5186,8 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
>> return err;
>>
>> err = pcim_iomap_regions(pdev, BIT(ICE_BAR0), dev_driver_string(dev));
>> - if (err) {
>> - dev_err(dev, "BAR0 I/O map error %d\n", err);
>> - return err;
>> - }
>> + if (err)
>> + return dev_err_probe(dev, err, "BAR0 I/O map error %d\n", err);
>>
>> pf = ice_allocate_pf(dev);
>> if (!pf)
>> @@ -5202,10 +5198,8 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
>>
>> /* set up for high or low DMA */
>> err = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
>> - if (err) {
>> - dev_err(dev, "DMA configuration failed: 0x%x\n", err);
>> - return err;
>> - }
>> + if (err)
>> + return dev_err_probe(dev, err, "DMA configuration failed: 0x%x\n", err);
>>
>> pci_set_master(pdev);
>> pf->pdev = pdev;
>> @@ -5240,10 +5234,8 @@ ice_probe(struct pci_dev *pdev, const struct pci_device_id __always_unused *ent)
>> return ice_probe_recovery_mode(pf);
>>
>> err = ice_init_hw(hw);
>> - if (err) {
>> - dev_err(dev, "ice_init_hw failed: %d\n", err);
>> - return err;
>> - }
>> + if (err)
>> + return dev_err_probe(dev, err, "ice_init_hw failed: %d\n", err);
>>
>> ice_init_dev_hw(pf);
>>
>> --
>> 2.25.1
>>
>>
^ permalink raw reply
* Re: [PATCH net-next v4 2/2] net: pse-pd: add Realtek/Broadcom PSE MCU driver
From: Oleksij Rempel @ 2026-07-02 7:13 UTC (permalink / raw)
To: Jonas Jelonek
Cc: Kory Maincent, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, netdev, devicetree, linux-kernel, Daniel Golle,
Bjørn Mork
In-Reply-To: <20260630105651.756058-3-jelonek.jonas@gmail.com>
Hi Jonas,
On Tue, Jun 30, 2026 at 10:56:50AM +0000, Jonas Jelonek wrote:
> A range of PoE switches use a small microcontroller on the PCB to front
> the actual PSE silicon. The host CPU talks to that MCU over I2C/SMBus or
> UART using a fixed 12-byte request/response protocol with a trailing
> checksum; the PSE chips are managed by the MCU and are not accessed
> directly. The same protocol family is spoken by Realtek and Broadcom PSE
> MCUs, diverging in opcode numbering and a few response layouts, which the
> driver abstracts behind a per-dialect opcode table and parser hooks
> selected by the compatible. The specific PSE chip behind the MCU is
> detected at runtime and only influences per-chip constants (power scaling
> and the per-port cap).
>
> The driver is split into a shared core and two transport modules:
>
> - PSE_REALTEK_MCU: protocol, message framing, dialect machinery, and the
> pse_controller_ops glue.
> - PSE_REALTEK_MCU_I2C / PSE_REALTEK_MCU_UART: transport modules
> registering the MCU on an I2C bus or a serdev port respectively.
>
> The realtek-pse-mcu-* files and PSE_REALTEK_MCU* symbols match the
> realtek,pse-mcu-rtk / realtek,pse-mcu-brcm compatibles: all name the
> Realtek PSE-MCU front-end, not the MCU silicon or the PSE chip behind
> it (see the binding for the prefix rationale). Broadcom PSE MCUs speak
> the same protocol family and are handled by the same shared core
> through the dialect abstraction selected by the '-brcm' compatible.
>
> Power budgeting is left to the MCU firmware; the driver advertises
> PSE_BUDGET_EVAL_STRAT_DYNAMIC (controller-managed budget) accordingly.
>
> Signed-off-by: Jonas Jelonek <jelonek.jonas@gmail.com>
LGTM, there are some nitpicks from my side
otherwise:
Acked-by: Oleksij Rempel <o.rempel@pengutronix.de>
...
> +/* Shorthand for the designated-initializer entries in dialect opcode tables. */
> +#define RTPSE_MCU_OP(opc) { .op = (opc), .valid = true }
> +
> +/* Forward-declared so dialects can supply response parsers (defined below). */
No forward declarations please move the structs here.
> +struct rtpse_mcu_info;
> +struct rtpse_mcu_port_status;
> +
> +struct rtpse_mcu_dialect {
> + struct rtpse_mcu_opcode opcode[RTPSE_MCU_NUM_CMDS];
> +
> + /*
> + * Response parsers. Each dialect must supply its own; the core calls
> + * these unconditionally rather than carrying a default that would
> + * silently mis-decode bytes from a dialect that forgot to set them.
> + */
> + int (*parse_system_info)(const u8 *payload, struct rtpse_mcu_info *info);
> + int (*parse_port_class)(const struct rtpse_mcu_port_status *status);
> + const char *(*mcu_type_str)(unsigned int mcu_type);
> +};
> +struct rtpse_mcu_port_config {
> + bool enable;
in this struct we use only enable, do you plan to wire it somewhere
later? I assume you wont to keep it as documentation. May be add some
debug traces? And add some comments what do you already know about this
fields.
> + u8 function_mode;
> + u8 detection_type;
> + u8 cls_type;
> + u8 disconnect_type;
> + u8 pair_type;
> +};
> +
> +struct rtpse_mcu_port_ext_config {
Same here.
> + u8 inrush_mode;
> + u8 limit_type;
> + u8 max_power;
> + u8 priority;
> + u8 chip_addr;
> + u8 channel;
> +};
> +static int rtpse_mcu_port_set_pw_limit(struct pse_controller_dev *pcdev, int id, int max_mW)
> +{
> + const struct rtpse_mcu_opcode *type_opc, *val_opc;
> + struct rtpse_mcu_ctrl *pse = to_rtpse_mcu_ctrl(pcdev);
> + const struct rtpse_mcu_chip_info *chip = pse->chip;
> + unsigned int prg_val;
> + int ret;
> +
> + if (max_mW < 0 || max_mW > chip->max_mW_per_port)
> + return -ERANGE;
> +
> + type_opc = &pse->dialect->opcode[RTPSE_MCU_CMD_PORT_SET_POWER_LIMIT_TYPE];
> + val_opc = &pse->dialect->opcode[chip->pw_set_cmd];
> + if (!type_opc->valid || !val_opc->valid)
> + return -EOPNOTSUPP;
> +
> + /*
> + * Switch the port to user-defined limit mode first, then program the
> + * limit value. If the second cmd fails, the port is left in
> + * user-defined mode but with the previous limit value; the next
> + * successful set_pw_limit call recovers it.
> + */
> + ret = rtpse_mcu_port_cmd(pse, id, type_opc->op, RTPSE_MCU_PORT_PW_LIMIT_TYPE_USER);
> + if (ret)
> + return ret;
> +
> + prg_val = min_t(unsigned int, max_mW / chip->pw_set_lsb_mW, 0xff);
Add some define for 0xff.
Can max_mW be zero?
> +
> + return rtpse_mcu_port_cmd(pse, id, val_opc->op, prg_val);
> +}
> +
> +static int rtpse_mcu_port_get_pw_limit_ranges(struct pse_controller_dev *pcdev, int id,
> + struct pse_pw_limit_ranges *out)
> +{
> + struct ethtool_c33_pse_pw_limit_range *range;
> + struct rtpse_mcu_ctrl *pse = to_rtpse_mcu_ctrl(pcdev);
In the drivers/net, All declarations should be in reverse tree style.
> + range = kzalloc_obj(*range, GFP_KERNEL);
> + if (!range)
> + return -ENOMEM;
> +
> + range[0].min = 0;
> + range[0].max = pse->chip->max_mW_per_port;
> +
> + out->c33_pw_limit_ranges = range;
> + return 1;
> +}
> +
> +static int rtpse_mcu_discover(struct rtpse_mcu_ctrl *pse, struct rtpse_mcu_info *info)
> +{
> + struct rtpse_mcu_ext_config ext_config;
> + unsigned long deadline;
> + int ret;
> +
> + /*
> + * The MCU may not answer on the bus yet right after power-up or
> + * enable-gpios assertion: depending on the transport it either stays
> + * silent (-ETIMEDOUT) or does not ACK its address at all (-ENXIO /
> + * -EREMOTEIO). Retry within a bounded wall-time window so a slow boot
> + * still probes, while a genuinely unresponsive MCU fails with its real
> + * error instead of deferring forever and masking it.
> + */
> + deadline = jiffies + msecs_to_jiffies(RTPSE_MCU_BOOT_TIMEOUT_MS);
> + do {
> + ret = rtpse_mcu_get_info(pse, info);
> + if (ret != -ETIMEDOUT && ret != -ENXIO && ret != -EREMOTEIO &&
> + ret != -EAGAIN)
For this section sashiko has an opinion:
https://sashiko.dev/#/patchset/20260630105651.756058-1-jelonek.jonas%40gmail.com
> + break;
> + msleep(RTPSE_MCU_BOOT_RETRY_MS);
> + } while (time_before(jiffies, deadline));
> + if (ret)
> + return dev_err_probe(pse->dev, ret, "failed to read MCU info\n");
> +
> + switch (info->device_id) {
> + case RTPSE_MCU_DEVICE_ID_RTL8238B:
> + pse->chip = &rtl8238b_info;
> + break;
> + case RTPSE_MCU_DEVICE_ID_RTL8239:
> + pse->chip = &rtl8239_info;
> + break;
> + case RTPSE_MCU_DEVICE_ID_RTL8239C:
> + pse->chip = &rtl8239c_info;
> + break;
> + case RTPSE_MCU_DEVICE_ID_BCM59111:
> + pse->chip = &bcm59111_info;
> + break;
> + case RTPSE_MCU_DEVICE_ID_BCM59121:
> + pse->chip = &bcm59121_info;
> + break;
> + default:
> + return dev_err_probe(pse->dev, -EINVAL, "unknown PSE id 0x%x\n",
> + info->device_id);
> + }
> +
> + if (!info->max_ports || info->max_ports > RTPSE_MCU_MAX_PORTS)
> + return dev_err_probe(pse->dev, -EINVAL,
> + "MCU reports invalid port count %u\n", info->max_ports);
> +
> + ret = rtpse_mcu_get_ext_config(pse, &ext_config);
> + if (ret)
> + return dev_err_probe(pse->dev, ret, "failed to read MCU ext config\n");
> +
> + dev_info(pse->dev, "%s MCU, %s (id 0x%04x), %u ports across %u PSE chip(s)\n",
> + pse->dialect->mcu_type_str(info->mcu_type), pse->chip->name,
> + info->device_id, info->max_ports, ext_config.num_of_pses);
Reduce it to debug level print.
> + return 0;
> +}
> +
Best Regards,
Oleksij
--
Pengutronix e.K. | |
Steuerwalder Str. 21 | http://www.pengutronix.de/ |
31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: arm: altera: Add Agilex5 SoCDK TSN Config2 board board
From: Krzysztof Kozlowski @ 2026-07-02 7:16 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade
Cc: dinguyen, maxime.chevallier, rmk+kernel, krzk+dt, conor+dt, robh,
davem, edumazet, kuba, pabeni, andrew+netdev, devicetree,
linux-arm-kernel, netdev, linux-kernel
In-Reply-To: <20260630133108.27244-2-muhammad.nazim.amirul.nazle.asmade@altera.com>
On Tue, Jun 30, 2026 at 06:31:06AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> Add compatible string for the Intel SoCFPGA Agilex5 SoCDK TSN Config2
> board variant, which uses a dual-port TSN configuration where gmac1
> operates with different MAC-side (GMII) and PHY-side (RGMII) interface
> modes.
>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> ---
> Documentation/devicetree/bindings/arm/altera.yaml | 1 +
> 1 file changed, 1 insertion(+)
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 2/3] arm64: dts: socfpga: agilex5: Add SoCDK TSN Config2 board
From: Krzysztof Kozlowski @ 2026-07-02 7:17 UTC (permalink / raw)
To: muhammad.nazim.amirul.nazle.asmade
Cc: dinguyen, maxime.chevallier, rmk+kernel, krzk+dt, conor+dt, robh,
davem, edumazet, kuba, pabeni, andrew+netdev, devicetree,
linux-arm-kernel, netdev, linux-kernel
In-Reply-To: <20260630133108.27244-3-muhammad.nazim.amirul.nazle.asmade@altera.com>
On Tue, Jun 30, 2026 at 06:31:07AM -0700, muhammad.nazim.amirul.nazle.asmade@altera.com wrote:
> From: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
>
> Add device tree for the Intel SoCFPGA Agilex5 SoCDK TSN Config2 board
> variant. This configuration enables gmac1 as a TSN port alongside
> the standard gmac2 Ethernet port.
>
> The TSN port (gmac1) uses GMII internally in the MAC but connects to an
> RGMII PHY. The mac-mode property is set to "gmii" to reflect the
> MAC-side interface, while phy-mode is set to "rgmii" for the PHY-side
> interface.
>
> Signed-off-by: Nazim Amirul <muhammad.nazim.amirul.nazle.asmade@altera.com>
> ---
> arch/arm64/boot/dts/intel/Makefile | 3 +-
> .../intel/socfpga_agilex5_socdk_tsn_cfg2.dts | 133 ++++++++++++++++++
> 2 files changed, 135 insertions(+), 1 deletion(-)
> create mode 100644 arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_tsn_cfg2.dts
>
> diff --git a/arch/arm64/boot/dts/intel/Makefile b/arch/arm64/boot/dts/intel/Makefile
> index 270c70fdf084..fc7ba2c6384b 100644
> --- a/arch/arm64/boot/dts/intel/Makefile
> +++ b/arch/arm64/boot/dts/intel/Makefile
> @@ -4,10 +4,11 @@ dtb-$(CONFIG_ARCH_INTEL_SOCFPGA) += socfpga_agilex_n6000.dtb \
> socfpga_agilex_socdk_emmc.dtb \
> socfpga_agilex_socdk_nand.dtb \
> socfpga_agilex3_socdk.dtb \
> - socfpga_agilex5_socdk.dtb \
> + socfpga_agilex5_socdk.dtb \
Why are you making this change?
> socfpga_agilex5_socdk_013b.dtb \
> socfpga_agilex5_socdk_modular.dtb \
> socfpga_agilex5_socdk_nand.dtb \
> + socfpga_agilex5_socdk_tsn_cfg2.dtb \
> socfpga_agilex72_socdk.dtb \
> socfpga_agilex7m_socdk.dtb \
> socfpga_n5x_socdk.dtb
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v1 net-next 1/2] ipv4: fib: Define fib_table_hash_lock under CONFIG_IP_MULTIPLE_TABLES.
From: Ido Schimmel @ 2026-07-02 7:17 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: David Ahern, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Kuniyuki Iwashima, netdev
In-Reply-To: <20260702044437.591864-2-kuniyu@google.com>
On Thu, Jul 02, 2026 at 04:44:14AM +0000, Kuniyuki Iwashima wrote:
> When CONFIG_IP_MULTIPLE_TABLES is disabled, fib_new_table()
> is fib_get_table(), and no new table is created.
>
> Let's move net->ipv4.fib_table_hash_lock under
> CONFIG_IP_MULTIPLE_TABLES.
>
> While at it, netns_ipv4_sysctl.rst is updated.
>
> Suggested-by: Ido Schimmel <idosch@nvidia.com>
> Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
^ permalink raw reply
* Re: [PATCH v1 net-next 2/2] net: fib_rules: Destroy ops->lock in fib_rules_unregister().
From: Ido Schimmel @ 2026-07-02 7:18 UTC (permalink / raw)
To: Kuniyuki Iwashima
Cc: David Ahern, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman, Kuniyuki Iwashima, netdev
In-Reply-To: <20260702044437.591864-3-kuniyu@google.com>
On Thu, Jul 02, 2026 at 04:44:15AM +0000, Kuniyuki Iwashima wrote:
> Commit 8e133ba99cd8 ("net: fib_rules: Add fib_rules_ops.lock.")
> added mutex in struct fib_rules_ops, which is initialised in
> fib_rules_register().
>
> Let's add paired mutex_destroy() in fib_rules_unregister().
>
> Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
^ permalink raw reply
* Re: [REGRESSION][BISECTED] tun/tap & vhost-net: multi-threaded network performance
From: Simon Schippers @ 2026-07-02 7:24 UTC (permalink / raw)
To: Michael S. Tsirkin, Brett Sheffield
Cc: regressions, netdev, Jakub Kicinski, Tim Gebauer,
Willem de Bruijn, Jason Wang, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, linux-kernel
In-Reply-To: <20260701165359-mutt-send-email-mst@kernel.org>
On 7/1/26 22:56, Michael S. Tsirkin wrote:
> On Wed, Jul 01, 2026 at 09:16:48PM +0200, Brett Sheffield wrote:
>> TL;DR - Commit 1d6e569b7d0c0b2736636749e4be0a27f3cefcb3 causes
>> significant performance regressions with TAP interfaces and multithreaded
>> network code. Please revert.
>>
>>
>> Librecast is an IPv6 multicast library. One of the tests (0055) fails under
>> Linux 7.2-rc1. The test performs data synchronization over IPv6 multicast using a TAP
>> interface. This test has run successfully on every stable, LTS and mainline RC
>> released in the past year. Every kernel with my Tested-by has run this test.
>>
>> There have been a bunch of changes to MLDv2 so I started bisecting there, but
>> the culprit is actually 1d6e569b7d0c0b2736636749e4be0a27f3cefcb3 "tun/tap &
>> vhost-net: avoid ptr_ring tail-drop when a qdisc is present"
>>
>> Reverting this commit fixes the test.
>>
>> To eliminate my code and any multicast weirdness, I ran tests with iperf3
>> comparing the same host running 7.2-rc1 both with and without 1d6e569b7d0
>> reverted.
Thank you very much for your bisect!
As the author, I am sorry for that regression!
>
> Thanks a lot for the bisect! Reverting is not out of question, but
> just before we do, it is worth analyzing the situation.
>
> Could you pls tell us
> - do you see packet drops?
iperf3 shows no TCP retransmissions, so there were never packet drops
when the patch was enabled.
It is the number after the sender data rate (example: threads 1,
reverted has 368 retransmissions/drops).
> - does it help to increase the tun queue size?
I agree, this would be great to know.
However, even then we must act. I am considering IFF_BACKPRESSURE
as a feature flag, defaulting to off. It would just enable/disable
the stopping logic in tun_net_xmit() and the waking logic
in __tun_wake_queue(). If disabled, it would result in the same logic
as before.
I could provide such a patch as [net] material.
Thanks again!
>
> Thanks a lot!
>
>
>> CPU: AMD Ryzen 9 9950X
>>
>> [ host ] - [ bridge ] - [ tap ] - [ guest (qemu) ]
>>
>> Running matching kernels on host and guest, I started iperf3 in server mode on
>> the guest and tested from the host so traffic passes through the tap interface.
>>
>> iperf3 -s -V # server
>> iperf3 -c guest -P nthreads # client
>>
>> 7.2.0-rc1 (threads 1):
>>
>> [ 5] 0.00-10.00 sec 20.2 GBytes 17.4 Gbits/sec 0 sender
>> [ 5] 0.00-10.00 sec 2.00 GBytes 1.72 Gbits/sec receiver
>>
>> 7.2.0-rc1 (threads 1, reverted):
>>
>> [ 5] 0.00-10.00 sec 15.3 GBytes 13.1 Gbits/sec 368 sender
>> [ 5] 0.00-10.00 sec 2.00 GBytes 1.72 Gbits/sec receiver
>>
>> 7.2.0-rc1 (threads 2):
>>
>> [SUM] 0.00-10.00 sec 10.9 GBytes 9.33 Gbits/sec 0 sender
>> [SUM] 0.00-10.00 sec 4.00 GBytes 3.43 Gbits/sec receiver
>>
>> 7.2.0-rc1 (threads 2, reverted):
>>
>> [SUM] 0.00-10.00 sec 15.9 GBytes 13.7 Gbits/sec 1567 sender
>> [SUM] 0.00-10.00 sec 4.00 GBytes 3.43 Gbits/sec receiver
>>
>> 7.2.0-rc1 (threads 4):
>>
>> [SUM] 0.00-10.00 sec 10.9 GBytes 9.33 Gbits/sec 0 sender
>> [SUM] 0.00-10.00 sec 8.00 GBytes 6.87 Gbits/sec receiver
>>
>> 7.2.0-rc1 (threads 4, reverted):
>>
>> [SUM] 0.00-10.00 sec 16.5 GBytes 14.1 Gbits/sec 6701 sender
>> [SUM] 0.00-10.00 sec 8.00 GBytes 6.87 Gbits/sec receiver
>>
>> 7.2.0-rc1 (threads 8):
>>
>> [SUM] 0.00-10.00 sec 10.7 GBytes 9.15 Gbits/sec 0 sender
>> [SUM] 0.00-10.01 sec 10.6 GBytes 9.13 Gbits/sec receiver
>>
>> 7.2.0-rc1 (threads 8, reverted):
>>
>> [SUM] 0.00-10.00 sec 16.2 GBytes 14.0 Gbits/sec 19319 sender
>> [SUM] 0.00-10.00 sec 15.7 GBytes 13.5 Gbits/sec receiver
>>
>> 7.2.0-rc1 (threads 16):
>>
>> [SUM] 0.00-10.00 sec 10.9 GBytes 9.35 Gbits/sec 0 sender
>> [SUM] 0.00-10.01 sec 10.9 GBytes 9.32 Gbits/sec receiver
>>
>> 7.2.0-rc1 (threads 16, reverted):
>>
>> [SUM] 0.00-10.00 sec 14.4 GBytes 12.4 Gbits/sec 43593 sender
>> [SUM] 0.00-10.00 sec 14.4 GBytes 12.4 Gbits/sec receiver
>>
>>
>> As you can see, the new code works for single threaded, but for all other cases
>> there's a significant performance drop. I see this trade-off is mentioned in the
>> commit, but the performance drop off is much worse than suggested with the
>> current patch.
>>
>> In our multicast use case data is sent by multiple threads to multiple groups
>> simultaneously, this just breaks things to the extent that a <2 second test
>> times out after 5 minutes.
>>
>>
>> git bisect start
>> # status: waiting for both good and bad commits
>> # bad: [dc59e4fea9d83f03bad6bddf3fa2e52491777482] Linux 7.2-rc1
>> git bisect bad dc59e4fea9d83f03bad6bddf3fa2e52491777482
>> # status: waiting for good commit(s), bad commit known
>> # good: [36bdc0e815b4e8a05b9028d8ef8a25e1ead35cc1] net: usb: asix: ax88772: re-add usbnet_link_change() in phylink callbacks
>> git bisect good 36bdc0e815b4e8a05b9028d8ef8a25e1ead35cc1
>> # good: [db314398f618a3a23315f73c87f7d318eaf06c1b] Merge branch 'net-bridge-mcast-support-exponential-field-encoding'
>> git bisect good db314398f618a3a23315f73c87f7d318eaf06c1b
>> # bad: [079a028d6327e68cfa5d38b36123637b321c19a7] string: Remove strncpy() from the kernel
>> git bisect bad 079a028d6327e68cfa5d38b36123637b321c19a7
>> # bad: [f396f4005180928cd9e15e352a6512865d3bc908] Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path
>> git bisect bad f396f4005180928cd9e15e352a6512865d3bc908
>> # bad: [ec1806a730a1c0b3d68a7f9afe81514fb0dd7991] netfilter: x_tables: disable 32bit compat interface in user namespaces
>> git bisect bad ec1806a730a1c0b3d68a7f9afe81514fb0dd7991
>> # good: [50c2d91c5dfa0e465826ec1f8dbad9cdc254bd85] mptcp: do not drop partial packets
>> git bisect good 50c2d91c5dfa0e465826ec1f8dbad9cdc254bd85
>> # good: [68993ced0f618e36cf33388f1e50223e5e6e78cc] Merge tag 'net-7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
>> git bisect good 68993ced0f618e36cf33388f1e50223e5e6e78cc
>> # good: [34c78dff59a25110a4ce50c208e42a91490fe615] Merge branch 'net-use-ip_outnoroutes-drop-reason'
>> git bisect good 34c78dff59a25110a4ce50c208e42a91490fe615
>> # bad: [9587ed8137fb83d93f84b858337412f4500b21e9] Merge branch 'gve-add-support-for-ptp-gettimex64'
>> git bisect bad 9587ed8137fb83d93f84b858337412f4500b21e9
>> # bad: [83ea7fd73b11dd8cbf4416507a5eac3890b49fb0] net: dsa: microchip: remove unused phylink_mac_link_up() callback
>> git bisect bad 83ea7fd73b11dd8cbf4416507a5eac3890b49fb0
>> # bad: [f0de88303d5e7e04a1224bc7a00512b5a1c4fe7a] net: make is_skb_wmem() available to modules
>> git bisect bad f0de88303d5e7e04a1224bc7a00512b5a1c4fe7a
>> # bad: [c411baa463e85a779a7e68a00ba6298770b58c4c] netconsole: move push_ipv6() from netpoll
>> git bisect bad c411baa463e85a779a7e68a00ba6298770b58c4c
>> # good: [fba362c17d9d9211fc51f272156bb84fc23bdf98] ptr_ring: move free-space check into separate helper
>> git bisect good fba362c17d9d9211fc51f272156bb84fc23bdf98
>> # bad: [d0273dbe8be1640e597552f81faf1d6c9997d3e3] ipvlan: use netif_receive_skb() in ipvlan_process_multicast()
>> git bisect bad d0273dbe8be1640e597552f81faf1d6c9997d3e3
>> # bad: [3803065cd6b0630d4161d86aa04e2d1db0f3a0b5] Merge branch 'tun-tap-vhost-net-apply-qdisc-backpressure-on-full-ptr_ring-to-reduce-tx-drops'
>> git bisect bad 3803065cd6b0630d4161d86aa04e2d1db0f3a0b5
>> # bad: [1d6e569b7d0c0b2736636749e4be0a27f3cefcb3] tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present
>> git bisect bad 1d6e569b7d0c0b2736636749e4be0a27f3cefcb3
>> # first bad commit: [1d6e569b7d0c0b2736636749e4be0a27f3cefcb3] tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present
>>
>> --
>> Brett Sheffield (he/him)
>> Librecast - Decentralising the Internet with Multicast
>> https://librecast.net/
>> https://blog.brettsheffield.com/
>
^ permalink raw reply
* Re: [PATCH bpf v3 3/4] selftests/bpf: Adapt sockmap update error handling
From: Michal Luczaj @ 2026-07-02 7:30 UTC (permalink / raw)
To: bot+bpf-ci, ast, daniel, andrii, eddyz87, memxor, martin.lau,
song, yonghong.song, jolsa, emil, shuah, john.fastabend, jakub,
jiayuan.chen, edumazet, kuniyu, pabeni, willemb, davem, kuba,
horms, cong.wang
Cc: bpf, linux-kselftest, linux-kernel, netdev, martin.lau, clm,
ihor.solodrai
In-Reply-To: <03d8ce102b71c68c30e98be36feaebe539055195c2323ec3b3fd84f157487afd@mail.kernel.org>
On 7/2/26 02:00, bot+bpf-ci@kernel.org wrote:
>> @@ -93,8 +90,12 @@ static void test_insert_bound(struct test_sockmap_listen *skel __always_unused,
>> errno = 0;
>> value = s;
>> err = bpf_map_update_elem(mapfd, &key, &value, BPF_NOEXIST);
>> - if (!err || errno != EOPNOTSUPP)
>> - FAIL_ERRNO("map_update: expected EOPNOTSUPP");
>> + if (sotype == SOCK_STREAM) {
>> + ASSERT_ERR(err, "map_update");
>> + ASSERT_EQ(errno, EOPNOTSUPP, "errno");
>> + } else if (err) {
>> + ASSERT_OK(err, "map_update");
>> + }
>
> This isn't a bug, but could the UDP branch just be `else ASSERT_OK(err,
> "map_update");` — the `if (err)` guard looks redundant since ASSERT_OK is
> a no-op on success?
Ugh, sorry. If there are no other comments for this series, I'd happy to
fix it later in bpf-next.
^ permalink raw reply
* [PATCH net v2] ipvs: fix PMTU for GUE/GRE tunnel ICMP errors
From: Yizhou Zhao @ 2026-07-02 7:34 UTC (permalink / raw)
To: netdev
Cc: Yizhou Zhao, Simon Horman, Julian Anastasov, Pablo Neira Ayuso,
Florian Westphal, Phil Sutter, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, lvs-devel, netfilter-devel, coreteam,
linux-kernel, stable, Yuxiang Yang, Ao Wang, Xuewei Feng, Qi Li,
Ke Xu
When an ICMP Fragmentation Needed error is received for a tunneled IPVS
connection, ip_vs_in_icmp() recomputes the MTU that the original packet
can use by subtracting the tunnel overhead from the reported next-hop
MTU.
The current code always subtracts sizeof(struct iphdr), which is only
the IPIP overhead. For GUE and GRE tunnels, ipvs_udp_decap() and
ipvs_gre_decap() already compute the additional tunnel header length,
but that value is scoped to the decapsulation block and is lost before
the ICMP_FRAG_NEEDED handling. As a result, the ICMP error sent back to
the client advertises an MTU that is too large, so PMTUD can fail to
converge for GUE/GRE-tunneled real servers.
With a reported next-hop MTU of 1400, a GUE tunnel currently returns
1380 to the client. The correct value is 1368:
1400 - sizeof(struct iphdr) - sizeof(struct udphdr) -
sizeof(struct guehdr)
Hoist the tunnel header length into the main ip_vs_in_icmp() scope and
subtract sizeof(struct iphdr) + ulen in the Fragmentation Needed path.
The IPIP path keeps ulen as 0, so its existing 1400 - 20 = 1380 result
is unchanged.
Fixes: 508f744c0de3 ("ipvs: strip udp tunnel headers from icmp errors")
Cc: stable@vger.kernel.org
Reported-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
Reported-by: Yuxiang Yang <yangyx22@mails.tsinghua.edu.cn>
Reported-by: Ao Wang <wangao@seu.edu.cn>
Reported-by: Xuewei Feng <fengxw06@126.com>
Reported-by: Qi Li <qli01@tsinghua.edu.cn>
Reported-by: Ke Xu <xuke@tsinghua.edu.cn>
Assisted-by: Claude-Code:GLM-5.2
Signed-off-by: Yizhou Zhao <zhaoyz24@mails.tsinghua.edu.cn>
---
Changes in v2:
- Use the short first hunk context so patch applies without fuzz.
- Adjust Assisted-by to checkpatch's agent-name format.
- Suggested by Julian.
- Link to v1: https://lore.kernel.org/netdev/20260701065941.46249-1-zhaoyz24@mails.tsinghua.edu.cn/
---
net/netfilter/ipvs/ip_vs_core.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_core.c b/net/netfilter/ipvs/ip_vs_core.c
index d40b404c1bf6..906f2c361676 100644
--- a/net/netfilter/ipvs/ip_vs_core.c
+++ b/net/netfilter/ipvs/ip_vs_core.c
@@ -1767,6 +1767,7 @@ ip_vs_in_icmp(struct netns_ipvs *ipvs, struct sk_buff *skb, int *related,
bool tunnel, new_cp = false;
union nf_inet_addr *raddr;
char *outer_proto = "IPIP";
+ int ulen = 0;
*related = 1;
@@ -1831,7 +1832,6 @@ ip_vs_in_icmp(struct netns_ipvs *ipvs, struct sk_buff *skb, int *related,
/* Error for our tunnel must arrive at LOCAL_IN */
(skb_rtable(skb)->rt_flags & RTCF_LOCAL)) {
__u8 iproto;
- int ulen;
/* Non-first fragment has no UDP/GRE header */
if (unlikely(cih->frag_off & htons(IP_OFFSET)))
@@ -1936,8 +1936,8 @@ ip_vs_in_icmp(struct netns_ipvs *ipvs, struct sk_buff *skb, int *related,
if (dest_dst)
mtu = dst_mtu(dest_dst->dst_cache);
}
- if (mtu > 68 + sizeof(struct iphdr))
- mtu -= sizeof(struct iphdr);
+ if (mtu > 68 + sizeof(struct iphdr) + ulen)
+ mtu -= sizeof(struct iphdr) + ulen;
info = htonl(mtu);
}
/* Strip outer IP, ICMP and IPIP/UDP/GRE, go to IP header of
^ permalink raw reply related
* RE: [PATCH net v2] cxgb4: flower: fix 802.1ad VLAN TPID matching in tc flower filters
From: Jagielski, Jedrzej @ 2026-07-02 7:35 UTC (permalink / raw)
To: Harsha M, netdev@vger.kernel.org
Cc: davem@davemloft.net, kuba@kernel.org, edumazet@google.com,
pabeni@redhat.com, andrew+netdev@lunn.ch, bharat@chelsio.com
In-Reply-To: <20260702044955.20119-1-h.mahadeva@chelsio.com>
From: Harsha M <h.mahadeva@chelsio.com>
Sent: Thursday, July 2, 2026 6:49 AM
>The cxgb4 driver does not correctly handle tc flower filters that
>match on an 802.1ad (Q-in-Q) outer VLAN tag. While the VLAN VID is
>processed, the specified 802.1ad TPID is not programmed into the
>adapter's outer VLAN matching configuration, resulting in incorrect
>filter matches.
>
>Fix this by configuring the port-specific OVLAN register with the
>requested TPID value, enabling OVLAN matching through the RX control
>register, and populating the filter specification with the outer VLAN
>VID and valid-bit match fields when an 802.1ad TPID is requested.This
>restores correct matching for tc flower filters that specify an 802.1ad
>outer VLAN tag
>
Hi
would be nice to have fixes tag
>Signed-off-by: Harsha M <h.mahadeva@chelsio.com>
>Signed-off-by: Potnuri Bharat Teja <bharat@chelsio.com>
>---
>v2:
>- Compare vlan_tpid with 'cpu_to_be16(ETH_P_8021AD)'
>- Program the OVLAN register using the ETH_P_8021AD constant
> and TPID mask as 0xffff instead of deriving the value from the
> filter key and mask
>v1:
>https://lore.kernel.org/all/20260629184417.31b21223@kernel.org/
>---
> .../ethernet/chelsio/cxgb4/cxgb4_tc_flower.c | 61 +++++++++++++------
> drivers/net/ethernet/chelsio/cxgb4/t4_regs.h | 3 +
> 2 files changed, 46 insertions(+), 18 deletions(-)
>
>diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
>index 3307e5042681..8c5cfa6982e7 100644
>--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
>+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_tc_flower.c
>@@ -40,6 +40,7 @@
> #include "cxgb4.h"
> #include "cxgb4_filter.h"
> #include "cxgb4_tc_flower.h"
>+#include "t4_regs.h"
>
> #define STATS_CHECK_PERIOD (HZ / 2)
>
>@@ -266,24 +267,48 @@ static void cxgb4_process_flow_match(struct net_device *dev,
> VLAN_PRIO_SHIFT);
> vlan_tci_mask = match.mask->vlan_id | (match.mask->vlan_priority <<
> VLAN_PRIO_SHIFT);
>- fs->val.ivlan = vlan_tci;
>- fs->mask.ivlan = vlan_tci_mask;
>-
>- fs->val.ivlan_vld = 1;
>- fs->mask.ivlan_vld = 1;
>-
>- /* Chelsio adapters use ivlan_vld bit to match vlan packets
>- * as 802.1Q. Also, when vlan tag is present in packets,
>- * ethtype match is used then to match on ethtype of inner
>- * header ie. the header following the vlan header.
>- * So, set the ivlan_vld based on ethtype info supplied by
>- * TC for vlan packets if its 802.1Q. And then reset the
>- * ethtype value else, hw will try to match the supplied
>- * ethtype value with ethtype of inner header.
>- */
>- if (fs->val.ethtype == ETH_P_8021Q) {
>- fs->val.ethtype = 0;
>- fs->mask.ethtype = 0;
>+
>+ if (match.key->vlan_tpid == cpu_to_be16(ETH_P_8021AD)) {
>+ struct adapter *adap = netdev2adap(dev);
>+ u32 ovlan_reg, ctl_reg, val, port_id;
>+
>+ if (!adap) {
is such scenario really even possible?
>+ netdev_err(dev, "%s: adap not found\n", __func__);
>+ return;
>+ }
>+
>+ val = (0xffff << 16) | ETH_P_8021AD;
>+ port_id = netdev2pinfo(dev)->port_id;
>+ fs->val.ovlan = vlan_tci;
>+ fs->mask.ovlan = vlan_tci_mask;
>+ fs->val.ovlan_vld = 1;
>+ fs->mask.ovlan_vld = 1;
>+ ovlan_reg = PORT_REG(port_id, MPS_PORT_RX_OVLAN0_A);
>+ ctl_reg = PORT_REG(port_id, MPS_PORT_RX_CTL_A);
>+ t4_write_reg(adap, ovlan_reg, val);
>+ val = t4_read_reg(adap, ctl_reg);
>+ t4_write_reg(adap, ctl_reg, val | 1);
>+ t4_tp_wr_bits_indirect(adap, TP_INGRESS_CONFIG_A, 1U << 9, 0);
>+ } else {
>+ fs->val.ivlan = vlan_tci;
>+ fs->mask.ivlan = vlan_tci_mask;
>+ fs->val.ivlan_vld = 1;
>+ fs->mask.ivlan_vld = 1;
>+
>+ /* Chelsio adapters use ivlan_vld bit to match vlan packets
>+ * as 802.1Q. Also, when vlan tag is present in packets,
>+ * ethtype match is used then to match on ethtype of inner
>+ * header ie. the header following the vlan header.
>+ * So, set the ivlan_vld based on ethtype info supplied by
>+ * TC for vlan packets if its 802.1Q. And then reset the
>+ * ethtype value else, hw will try to match the supplied
>+ * ethtype value with ethtype of inner header.
>+ */
>+
isn't this already fs->val.ethtype != ETH_P_8021Q branch and fs has not
been modified since entering?
>+ if (fs->val.ethtype == ETH_P_8021Q) {
>+ fs->val.ethtype = 0;
>+ fs->mask.ethtype = 0;
>+ }
> }
> }
>
>diff --git a/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h b/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
>index 695916ba0405..38c585f3b1ad 100644
>--- a/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
>+++ b/drivers/net/ethernet/chelsio/cxgb4/t4_regs.h
>@@ -1921,6 +1921,9 @@
> #define MAC_PORT_PTP_SUM_LO_A 0x990
> #define MAC_PORT_PTP_SUM_HI_A 0x994
>
>+#define MPS_PORT_RX_OVLAN0_A 0x120
>+#define MPS_PORT_RX_CTL_A 0X100
>+
> #define MPS_CMN_CTL_A 0x9000
>
> #define COUNTPAUSEMCRX_S 5
>--
>2.43.5
^ permalink raw reply
* Re: [PATCH net] net/mlx5: HWS, fix matcher leak on resize target setup failure
From: patchwork-bot+netdevbpf @ 2026-07-02 7:40 UTC (permalink / raw)
To: Dawei Feng
Cc: saeedm, leon, tariqt, mbloch, andrew+netdev, davem, edumazet,
kuba, pabeni, kliteyn, vdogaru, horms, kees, stable, netdev,
linux-rdma, linux-kernel, jianhao.xu, zilin
In-Reply-To: <20260629064049.3852759-1-dawei.feng@seu.edu.cn>
Hello:
This patch was applied to netdev/net.git (main)
by Paolo Abeni <pabeni@redhat.com>:
On Mon, 29 Jun 2026 14:40:49 +0800 you wrote:
> hws_bwc_matcher_move() allocates a replacement matcher before setting it
> as the resize target. If mlx5hws_matcher_resize_set_target() fails, the
> replacement matcher is not attached anywhere and is leaked.
>
> Fix the leak by destroying the replacement matcher before returning from
> the resize-target failure path.
>
> [...]
Here is the summary with links:
- [net] net/mlx5: HWS, fix matcher leak on resize target setup failure
https://git.kernel.org/netdev/net/c/bb09d0e64eca
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net-next V4 4/6] devlink: Apply eswitch mode boot defaults
From: Paolo Abeni @ 2026-07-02 7:41 UTC (permalink / raw)
To: Mark Bloch, Jiri Pirko, Eric Dumazet, Jakub Kicinski,
Simon Horman
Cc: Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Andrew Lunn,
Jonathan Corbet, Shuah Khan, netdev, linux-rdma, linux-doc
In-Reply-To: <20260629182102.245150-5-mbloch@nvidia.com>
On 6/29/26 8:20 PM, Mark Bloch wrote:
> Apply parsed devlink_eswitch_mode= defaults after devlink registration
> and after successful reload.
>
> devl_register() may still be called before the device is ready for an
> eswitch mode change, so keep a per-devlink delayed work item and pending
> flag for the registration path. Registration queues the work, and the
> worker tries to take the devlink instance lock.
>
> If the lock is busy, the worker requeues itself with a delay.
>
> For successful reloads that performed DRIVER_REINIT, devlink_reload()
> already holds the devlink instance lock and the driver has completed
> reload_up(). Clear pending work and apply the default directly from the
> reload path instead of queueing work.
>
> If a user sets eswitch mode through netlink before the pending
> registration work runs, clear the pending flag so the queued default does
> not override that user request. Cancel pending default apply work when
> freeing the devlink instance.
>
> Signed-off-by: Mark Bloch <mbloch@nvidia.com>
> ---
> net/devlink/core.c | 198 +++++++++++++++++++++++++++++++-----
> net/devlink/dev.c | 6 ++
> net/devlink/devl_internal.h | 5 +
> 3 files changed, 182 insertions(+), 27 deletions(-)
>
> diff --git a/net/devlink/core.c b/net/devlink/core.c
> index 5126509a9c4e..998e4ffd5dce 100644
> --- a/net/devlink/core.c
> +++ b/net/devlink/core.c
> @@ -5,6 +5,7 @@
> */
>
> #include <linux/init.h>
> +#include <linux/jiffies.h>
> #include <linux/list.h>
> #include <linux/slab.h>
> #include <linux/string.h>
> @@ -22,8 +23,12 @@ DEFINE_XARRAY_FLAGS(devlinks, XA_FLAGS_ALLOC);
>
> static char *devlink_default_esw_mode_param;
> static bool devlink_default_esw_mode_match_all;
> +static bool devlink_default_esw_mode_enabled;
> static enum devlink_eswitch_mode devlink_default_esw_mode;
> static LIST_HEAD(devlink_default_esw_mode_nodes);
> +static struct workqueue_struct *devlink_default_esw_mode_wq;
> +
> +#define DEVLINK_DEFAULT_ESW_MODE_APPLY_DELAY msecs_to_jiffies(100)
>
> struct devlink_default_esw_mode_node {
> struct list_head list;
> @@ -166,6 +171,7 @@ static void __init devlink_default_esw_mode_nodes_clear(void)
> }
>
> devlink_default_esw_mode_match_all = false;
> + devlink_default_esw_mode_enabled = false;
> }
>
> static int __init devlink_default_esw_mode_parse(char *str)
> @@ -192,14 +198,113 @@ static int __init devlink_default_esw_mode_parse(char *str)
> return err;
>
> err = devlink_default_esw_mode_handles_parse(handles);
> - if (err)
> + if (err) {
> devlink_default_esw_mode_nodes_clear();
> - else
> + } else {
> devlink_default_esw_mode = esw_mode;
> + devlink_default_esw_mode_enabled = true;
> + }
>
> return err;
> }
>
> +static bool devlink_default_esw_mode_match(struct devlink *devlink)
> +{
> + const char *bus_name = devlink_bus_name(devlink);
> + const char *dev_name = devlink_dev_name(devlink);
> + struct devlink_default_esw_mode_node *node;
> +
> + if (devlink_default_esw_mode_match_all)
> + return true;
> +
> + node = devlink_default_esw_mode_node_find(bus_name, dev_name);
> + return !!node;
> +}
> +
> +void devlink_default_esw_mode_apply(struct devlink *devlink)
> +{
> + const struct devlink_ops *ops = devlink->ops;
> + int err;
> +
> + devl_assert_locked(devlink);
> +
> + if (!devlink_default_esw_mode_match(devlink))
> + return;
> +
> + if (!ops->eswitch_mode_set) {
> + if (!devlink_default_esw_mode_match_all)
> + devl_warn(devlink,
> + "devlink_eswitch_mode= selected this device but eswitch mode setting is not supported\n");
Not a very strong opinion on my side, but I *think* it would be more
consistent to emit this warning even for devlink_default_esw_mode_match_all
/P
^ permalink raw reply
* Re: [REGRESSION][BISECTED] tun/tap & vhost-net: multi-threaded network performance
From: Michael S. Tsirkin @ 2026-07-02 7:42 UTC (permalink / raw)
To: Simon Schippers
Cc: Brett Sheffield, regressions, netdev, Jakub Kicinski, Tim Gebauer,
Willem de Bruijn, Jason Wang, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, linux-kernel
In-Reply-To: <ef33f0a7-f0b7-4bc4-9263-10d2b480d717@tu-dortmund.de>
On Thu, Jul 02, 2026 at 09:24:59AM +0200, Simon Schippers wrote:
> On 7/1/26 22:56, Michael S. Tsirkin wrote:
> > On Wed, Jul 01, 2026 at 09:16:48PM +0200, Brett Sheffield wrote:
> >> TL;DR - Commit 1d6e569b7d0c0b2736636749e4be0a27f3cefcb3 causes
> >> significant performance regressions with TAP interfaces and multithreaded
> >> network code. Please revert.
> >>
> >>
> >> Librecast is an IPv6 multicast library. One of the tests (0055) fails under
> >> Linux 7.2-rc1. The test performs data synchronization over IPv6 multicast using a TAP
> >> interface. This test has run successfully on every stable, LTS and mainline RC
> >> released in the past year. Every kernel with my Tested-by has run this test.
> >>
> >> There have been a bunch of changes to MLDv2 so I started bisecting there, but
> >> the culprit is actually 1d6e569b7d0c0b2736636749e4be0a27f3cefcb3 "tun/tap &
> >> vhost-net: avoid ptr_ring tail-drop when a qdisc is present"
> >>
> >> Reverting this commit fixes the test.
> >>
> >> To eliminate my code and any multicast weirdness, I ran tests with iperf3
> >> comparing the same host running 7.2-rc1 both with and without 1d6e569b7d0
> >> reverted.
>
> Thank you very much for your bisect!
>
> As the author, I am sorry for that regression!
>
> >
> > Thanks a lot for the bisect! Reverting is not out of question, but
> > just before we do, it is worth analyzing the situation.
> >
> > Could you pls tell us
> > - do you see packet drops?
>
> iperf3 shows no TCP retransmissions, so there were never packet drops
> when the patch was enabled.
> It is the number after the sender data rate (example: threads 1,
> reverted has 368 retransmissions/drops).
>
> > - does it help to increase the tun queue size?
>
> I agree, this would be great to know.
>
> However, even then we must act. I am considering IFF_BACKPRESSURE
> as a feature flag, defaulting to off. It would just enable/disable
> the stopping logic in tun_net_xmit() and the waking logic
> in __tun_wake_queue(). If disabled, it would result in the same logic
> as before.
>
> I could provide such a patch as [net] material.
>
> Thanks again!
Or BQL? I quickly wrote a prototype of that and it seems to work well -
could you help test maybe?
> >
> > Thanks a lot!
> >
> >
> >> CPU: AMD Ryzen 9 9950X
> >>
> >> [ host ] - [ bridge ] - [ tap ] - [ guest (qemu) ]
> >>
> >> Running matching kernels on host and guest, I started iperf3 in server mode on
> >> the guest and tested from the host so traffic passes through the tap interface.
> >>
> >> iperf3 -s -V # server
> >> iperf3 -c guest -P nthreads # client
> >>
> >> 7.2.0-rc1 (threads 1):
> >>
> >> [ 5] 0.00-10.00 sec 20.2 GBytes 17.4 Gbits/sec 0 sender
> >> [ 5] 0.00-10.00 sec 2.00 GBytes 1.72 Gbits/sec receiver
> >>
> >> 7.2.0-rc1 (threads 1, reverted):
> >>
> >> [ 5] 0.00-10.00 sec 15.3 GBytes 13.1 Gbits/sec 368 sender
> >> [ 5] 0.00-10.00 sec 2.00 GBytes 1.72 Gbits/sec receiver
> >>
> >> 7.2.0-rc1 (threads 2):
> >>
> >> [SUM] 0.00-10.00 sec 10.9 GBytes 9.33 Gbits/sec 0 sender
> >> [SUM] 0.00-10.00 sec 4.00 GBytes 3.43 Gbits/sec receiver
> >>
> >> 7.2.0-rc1 (threads 2, reverted):
> >>
> >> [SUM] 0.00-10.00 sec 15.9 GBytes 13.7 Gbits/sec 1567 sender
> >> [SUM] 0.00-10.00 sec 4.00 GBytes 3.43 Gbits/sec receiver
> >>
> >> 7.2.0-rc1 (threads 4):
> >>
> >> [SUM] 0.00-10.00 sec 10.9 GBytes 9.33 Gbits/sec 0 sender
> >> [SUM] 0.00-10.00 sec 8.00 GBytes 6.87 Gbits/sec receiver
> >>
> >> 7.2.0-rc1 (threads 4, reverted):
> >>
> >> [SUM] 0.00-10.00 sec 16.5 GBytes 14.1 Gbits/sec 6701 sender
> >> [SUM] 0.00-10.00 sec 8.00 GBytes 6.87 Gbits/sec receiver
> >>
> >> 7.2.0-rc1 (threads 8):
> >>
> >> [SUM] 0.00-10.00 sec 10.7 GBytes 9.15 Gbits/sec 0 sender
> >> [SUM] 0.00-10.01 sec 10.6 GBytes 9.13 Gbits/sec receiver
> >>
> >> 7.2.0-rc1 (threads 8, reverted):
> >>
> >> [SUM] 0.00-10.00 sec 16.2 GBytes 14.0 Gbits/sec 19319 sender
> >> [SUM] 0.00-10.00 sec 15.7 GBytes 13.5 Gbits/sec receiver
> >>
> >> 7.2.0-rc1 (threads 16):
> >>
> >> [SUM] 0.00-10.00 sec 10.9 GBytes 9.35 Gbits/sec 0 sender
> >> [SUM] 0.00-10.01 sec 10.9 GBytes 9.32 Gbits/sec receiver
> >>
> >> 7.2.0-rc1 (threads 16, reverted):
> >>
> >> [SUM] 0.00-10.00 sec 14.4 GBytes 12.4 Gbits/sec 43593 sender
> >> [SUM] 0.00-10.00 sec 14.4 GBytes 12.4 Gbits/sec receiver
> >>
> >>
> >> As you can see, the new code works for single threaded, but for all other cases
> >> there's a significant performance drop. I see this trade-off is mentioned in the
> >> commit, but the performance drop off is much worse than suggested with the
> >> current patch.
> >>
> >> In our multicast use case data is sent by multiple threads to multiple groups
> >> simultaneously, this just breaks things to the extent that a <2 second test
> >> times out after 5 minutes.
> >>
> >>
> >> git bisect start
> >> # status: waiting for both good and bad commits
> >> # bad: [dc59e4fea9d83f03bad6bddf3fa2e52491777482] Linux 7.2-rc1
> >> git bisect bad dc59e4fea9d83f03bad6bddf3fa2e52491777482
> >> # status: waiting for good commit(s), bad commit known
> >> # good: [36bdc0e815b4e8a05b9028d8ef8a25e1ead35cc1] net: usb: asix: ax88772: re-add usbnet_link_change() in phylink callbacks
> >> git bisect good 36bdc0e815b4e8a05b9028d8ef8a25e1ead35cc1
> >> # good: [db314398f618a3a23315f73c87f7d318eaf06c1b] Merge branch 'net-bridge-mcast-support-exponential-field-encoding'
> >> git bisect good db314398f618a3a23315f73c87f7d318eaf06c1b
> >> # bad: [079a028d6327e68cfa5d38b36123637b321c19a7] string: Remove strncpy() from the kernel
> >> git bisect bad 079a028d6327e68cfa5d38b36123637b321c19a7
> >> # bad: [f396f4005180928cd9e15e352a6512865d3bc908] Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path
> >> git bisect bad f396f4005180928cd9e15e352a6512865d3bc908
> >> # bad: [ec1806a730a1c0b3d68a7f9afe81514fb0dd7991] netfilter: x_tables: disable 32bit compat interface in user namespaces
> >> git bisect bad ec1806a730a1c0b3d68a7f9afe81514fb0dd7991
> >> # good: [50c2d91c5dfa0e465826ec1f8dbad9cdc254bd85] mptcp: do not drop partial packets
> >> git bisect good 50c2d91c5dfa0e465826ec1f8dbad9cdc254bd85
> >> # good: [68993ced0f618e36cf33388f1e50223e5e6e78cc] Merge tag 'net-7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
> >> git bisect good 68993ced0f618e36cf33388f1e50223e5e6e78cc
> >> # good: [34c78dff59a25110a4ce50c208e42a91490fe615] Merge branch 'net-use-ip_outnoroutes-drop-reason'
> >> git bisect good 34c78dff59a25110a4ce50c208e42a91490fe615
> >> # bad: [9587ed8137fb83d93f84b858337412f4500b21e9] Merge branch 'gve-add-support-for-ptp-gettimex64'
> >> git bisect bad 9587ed8137fb83d93f84b858337412f4500b21e9
> >> # bad: [83ea7fd73b11dd8cbf4416507a5eac3890b49fb0] net: dsa: microchip: remove unused phylink_mac_link_up() callback
> >> git bisect bad 83ea7fd73b11dd8cbf4416507a5eac3890b49fb0
> >> # bad: [f0de88303d5e7e04a1224bc7a00512b5a1c4fe7a] net: make is_skb_wmem() available to modules
> >> git bisect bad f0de88303d5e7e04a1224bc7a00512b5a1c4fe7a
> >> # bad: [c411baa463e85a779a7e68a00ba6298770b58c4c] netconsole: move push_ipv6() from netpoll
> >> git bisect bad c411baa463e85a779a7e68a00ba6298770b58c4c
> >> # good: [fba362c17d9d9211fc51f272156bb84fc23bdf98] ptr_ring: move free-space check into separate helper
> >> git bisect good fba362c17d9d9211fc51f272156bb84fc23bdf98
> >> # bad: [d0273dbe8be1640e597552f81faf1d6c9997d3e3] ipvlan: use netif_receive_skb() in ipvlan_process_multicast()
> >> git bisect bad d0273dbe8be1640e597552f81faf1d6c9997d3e3
> >> # bad: [3803065cd6b0630d4161d86aa04e2d1db0f3a0b5] Merge branch 'tun-tap-vhost-net-apply-qdisc-backpressure-on-full-ptr_ring-to-reduce-tx-drops'
> >> git bisect bad 3803065cd6b0630d4161d86aa04e2d1db0f3a0b5
> >> # bad: [1d6e569b7d0c0b2736636749e4be0a27f3cefcb3] tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present
> >> git bisect bad 1d6e569b7d0c0b2736636749e4be0a27f3cefcb3
> >> # first bad commit: [1d6e569b7d0c0b2736636749e4be0a27f3cefcb3] tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present
> >>
> >> --
> >> Brett Sheffield (he/him)
> >> Librecast - Decentralising the Internet with Multicast
> >> https://librecast.net/
> >> https://blog.brettsheffield.com/
> >
^ permalink raw reply
* [syzbot ci] Re: net: Support per-netns device unregistration
From: syzbot ci @ 2026-07-02 7:45 UTC (permalink / raw)
To: andrew, davem, edumazet, horms, kuba, kuni1840, kuniyu, netdev,
pabeni
Cc: syzbot, syzkaller-bugs
In-Reply-To: <20260701214334.266991-1-kuniyu@google.com>
syzbot ci has tested the following series
[v1] net: Support per-netns device unregistration
https://lore.kernel.org/all/20260701214334.266991-1-kuniyu@google.com
* [PATCH v1 net-next 01/14] rtnetlink: Lock sock_net(skb->sk) in rtnl_newlink().
* [PATCH v1 net-next 02/14] rtnetlink: Call unregister_netdevice_many() only once in rtnl_link_unregister().
* [PATCH v1 net-next 03/14] rtnetlink: Add per-netns rtnl_work.
* [PATCH v1 net-next 04/14] net: Wrap default_device_exit_net() with __rtnl_net_lock().
* [PATCH v1 net-next 05/14] net: Hold __rtnl_net_lock() in netdev_wait_allrefs_any().
* [PATCH v1 net-next 06/14] net: Add per-netns netdev unregistration infra.
* [PATCH v1 net-next 07/14] net: Call unregister_netdevice_many() per netns.
* [PATCH v1 net-next 08/14] veth: Support per-netns device unregistration.
* [PATCH v1 net-next 09/14] bareudp: Protect bareudp_list with mutex.
* [PATCH v1 net-next 10/14] bareudp: Support per-netns netdev unregistration.
* [PATCH v1 net-next 11/14] ipvlan: Convert ipvl_port.count to refcount_t.
* [PATCH v1 net-next 12/14] ipvlan: Synchronise ipvlan_init() and ipvlan_uninit() for the same lower dev.
* [PATCH v1 net-next 13/14] ipvlan: Protect ipvl_port.ipvlans with mutex.
* [PATCH v1 net-next 14/14] ipvlan: Support per-netns netdev unregistration.
and found the following issue:
possible deadlock in __dev_change_net_namespace
Full report is available here:
https://ci.syzbot.org/series/a744b257-d741-4780-8a53-f156b2a7afc9
***
possible deadlock in __dev_change_net_namespace
tree: net-next
URL: https://kernel.googlesource.com/pub/scm/linux/kernel/git/netdev/net-next.git
base: d6e81529749190123aa0040626c7e5dbc20fdc9a
arch: amd64
compiler: Debian clang version 22.1.6 (++20260514074242+fc4aad7b5db3-1~exp1~20260514074407.73), Debian LLD 22.1.6
config: https://ci.syzbot.org/builds/243cd0ec-28f9-4d21-8f16-3d2fbad8388d/config
syz repro: https://ci.syzbot.org/findings/a8a0740d-fdec-4a20-9aa5-7cb955707913/syz_repro
veth0_macvtap: left promiscuous mode
============================================
WARNING: possible recursive locking detected
syzkaller #0 Not tainted
--------------------------------------------
syz.1.18/5814 is trying to acquire lock:
ffffffff9a9b0418 (&net->dev_unreg_lock){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline]
ffffffff9a9b0418 (&net->dev_unreg_lock){+.+.}-{3:3}, at: unregister_netdevice_move_net net/core/dev.c:-1 [inline]
ffffffff9a9b0418 (&net->dev_unreg_lock){+.+.}-{3:3}, at: __dev_change_net_namespace+0x1479/0x2200 net/core/dev.c:12768
but task is already holding lock:
ffff88810b6cf8d8 (&net->dev_unreg_lock){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline]
ffff88810b6cf8d8 (&net->dev_unreg_lock){+.+.}-{3:3}, at: unregister_netdevice_move_net net/core/dev.c:-1 [inline]
ffff88810b6cf8d8 (&net->dev_unreg_lock){+.+.}-{3:3}, at: __dev_change_net_namespace+0x146a/0x2200 net/core/dev.c:12768
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&net->dev_unreg_lock);
lock(&net->dev_unreg_lock);
*** DEADLOCK ***
May be due to missing lock nesting notation
4 locks held by syz.1.18/5814:
#0: ffffffff8fdeb0c0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_lock net/core/rtnetlink.c:80 [inline]
#0: ffffffff8fdeb0c0 (rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x2a/0x2b0 net/core/rtnetlink.c:366
#1: ffffffff9a9b0380 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0x76/0x2b0 net/core/rtnetlink.c:369
#2: ffff88810b6cf840 (&net->rtnl_mutex){+.+.}-{4:4}, at: rtnl_nets_lock+0xbf/0x2b0 net/core/rtnetlink.c:369
#3: ffff88810b6cf8d8 (&net->dev_unreg_lock){+.+.}-{3:3}, at: spin_lock include/linux/spinlock.h:342 [inline]
#3: ffff88810b6cf8d8 (&net->dev_unreg_lock){+.+.}-{3:3}, at: unregister_netdevice_move_net net/core/dev.c:-1 [inline]
#3: ffff88810b6cf8d8 (&net->dev_unreg_lock){+.+.}-{3:3}, at: __dev_change_net_namespace+0x146a/0x2200 net/core/dev.c:12768
stack backtrace:
CPU: 0 UID: 0 PID: 5814 Comm: syz.1.18 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_deadlock_bug+0x279/0x290 kernel/locking/lockdep.c:3041
check_deadlock kernel/locking/lockdep.c:3093 [inline]
validate_chain kernel/locking/lockdep.c:3895 [inline]
__lock_acquire+0x24df/0x2cf0 kernel/locking/lockdep.c:5237
lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5868
__raw_spin_lock include/linux/spinlock_api_smp.h:158 [inline]
_raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:158
spin_lock include/linux/spinlock.h:342 [inline]
unregister_netdevice_move_net net/core/dev.c:-1 [inline]
__dev_change_net_namespace+0x1479/0x2200 net/core/dev.c:12768
do_setlink+0x2d1/0x4670 net/core/rtnetlink.c:3148
rtnl_changelink net/core/rtnetlink.c:3880 [inline]
__rtnl_newlink net/core/rtnetlink.c:4053 [inline]
rtnl_newlink+0x1612/0x1b50 net/core/rtnetlink.c:4192
rtnetlink_rcv_msg+0x802/0xc00 net/core/rtnetlink.c:7109
netlink_rcv_skb+0x226/0x4a0 net/netlink/af_netlink.c:2556
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x7bb/0x940 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1900
sock_sendmsg_nosec+0x13a/0x180 net/socket.c:775
__sock_sendmsg net/socket.c:790 [inline]
____sys_sendmsg+0x54e/0x850 net/socket.c:2684
___sys_sendmsg+0x2a5/0x360 net/socket.c:2738
__sys_sendmsg net/socket.c:2770 [inline]
__do_sys_sendmsg net/socket.c:2775 [inline]
__se_sys_sendmsg net/socket.c:2773 [inline]
__x64_sys_sendmsg+0x1b1/0x290 net/socket.c:2773
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7fbdc639ce59
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fbdc59fe028 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007fbdc6615fa0 RCX: 00007fbdc639ce59
RDX: 0000000000000000 RSI: 0000200000000740 RDI: 0000000000000003
RBP: 00007fbdc6432e6f R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fbdc6616038 R14: 00007fbdc6615fa0 R15: 00007ffd94dcb1f8
</TASK>
syz.1.18 (5814) used greatest stack depth: 19864 bytes left
***
If these findings have caused you to resend the series or submit a
separate fix, please add the following tag to your commit message:
Tested-by: syzbot@syzkaller.appspotmail.com
---
This report is generated by a bot. It may contain errors.
syzbot ci engineers can be reached at syzkaller@googlegroups.com.
To test a patch for this bug, please reply with `#syz test`
(should be on a separate line).
The patch should be attached to the email.
Note: arguments like custom git repos and branches are not supported.
^ permalink raw reply
* [PATCH net-next v3] selftests/net/openvswitch: add output truncation test
From: Minxi Hou @ 2026-07-02 7:49 UTC (permalink / raw)
To: netdev
Cc: Minxi Hou, aconole, echaudro, i.maximets, davem, edumazet, kuba,
pabeni, horms, shuah, dev, linux-kselftest
Add test_trunc exercising the OVS_ACTION_ATTR_TRUNC action. The test
verifies truncation limits in four steps: reject trunc(1) and
trunc(13) which are below ETH_HLEN, confirm normal forwarding works,
apply trunc(14) which truncates packets to the Ethernet header and
verify ping fails, then restore normal forwarding and verify recovery.
The kernel requires max_len >= ETH_HLEN (14 bytes). trunc(14) sets
OVS_CB(skb)->cutlen so pskb_trim strips the IP payload at output
time; the receiver drops the runt frame and no echo reply is
generated.
Signed-off-by: Minxi Hou <houminxi@gmail.com>
---
.../selftests/net/openvswitch/openvswitch.sh | 87 +++++++++++++++++++
1 file changed, 87 insertions(+)
diff --git a/tools/testing/selftests/net/openvswitch/openvswitch.sh b/tools/testing/selftests/net/openvswitch/openvswitch.sh
index 2954245129a2..f75ee723415a 100755
--- a/tools/testing/selftests/net/openvswitch/openvswitch.sh
+++ b/tools/testing/selftests/net/openvswitch/openvswitch.sh
@@ -32,6 +32,7 @@ tests="
dec_ttl ttl: dec_ttl decrements IP TTL
flow_set flow-set: Flow modify
action_set set: SET action rewrites fields
+ trunc trunc: output truncation
psample psample: Sampling packets with psample"
info() {
@@ -443,6 +444,92 @@ test_action_set() {
return 0
}
+# trunc test
+# - trunc(14): truncate to ETH_HLEN, strips IP payload, ping fails
+# - trunc(1) and trunc(13): kernel rejects below ETH_HLEN (EINVAL)
+# - restore normal forwarding and verify recovery
+test_trunc() {
+ sbx_add "test_trunc" || return $?
+ ovs_add_dp "test_trunc" trunctest || return 1
+
+ info "create namespaces"
+ for ns in client server; do
+ ovs_add_netns_and_veths "test_trunc" "trunctest" \
+ "$ns" "${ns:0:1}0" "${ns:0:1}1" || return 1
+ done
+
+ ip netns exec client ip addr add 10.0.0.1/24 dev c1
+ ip netns exec client ip link set c1 up
+ ip netns exec server ip addr add 10.0.0.2/24 dev s1
+ ip netns exec server ip link set s1 up
+
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(1),eth(),eth_type(0x0806),arp()' '2' || return 1
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(2),eth(),eth_type(0x0806),arp()' '1' || return 1
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(1),eth(),eth_type(0x0800),ipv4()' \
+ '2' || return 1
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(2),eth(),eth_type(0x0800),ipv4()' \
+ '1' || return 1
+
+ info "verify connectivity without truncation"
+ ovs_sbx "test_trunc" ip netns exec client \
+ ping -c 1 -W 2 10.0.0.2 || return 1
+
+ # trunc below ETH_HLEN must be rejected by the kernel
+ info "verify trunc(1) is rejected"
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(1),eth(),eth_type(0x0800),ipv4()' \
+ 'trunc(1),2' &> /dev/null \
+ && { info "trunc(1) should be rejected"; return 1; }
+
+ info "verify trunc(13) is rejected"
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(1),eth(),eth_type(0x0800),ipv4()' \
+ 'trunc(13),2' &> /dev/null \
+ && { info "trunc(13) should be rejected"; return 1; }
+
+ ovs_del_flows "test_trunc" trunctest
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(1),eth(),eth_type(0x0806),arp()' '2' || return 1
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(2),eth(),eth_type(0x0806),arp()' '1' || return 1
+
+ info "add trunc(14) forwarding flow"
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(1),eth(),eth_type(0x0800),ipv4()' \
+ 'trunc(14),2' || return 1
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(2),eth(),eth_type(0x0800),ipv4()' \
+ '1' || return 1
+
+ info "verify ping fails with trunc(14)"
+ ovs_sbx "test_trunc" ip netns exec client \
+ ping -c 1 -W 2 10.0.0.2 >/dev/null 2>&1 \
+ && { info "ping should fail with trunc(14)"
+ return 1; }
+
+ ovs_del_flows "test_trunc" trunctest
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(1),eth(),eth_type(0x0806),arp()' '2' || return 1
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(2),eth(),eth_type(0x0806),arp()' '1' || return 1
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(1),eth(),eth_type(0x0800),ipv4()' \
+ '2' || return 1
+ ovs_add_flow "test_trunc" trunctest \
+ 'in_port(2),eth(),eth_type(0x0800),ipv4()' \
+ '1' || return 1
+
+ info "verify connectivity restored"
+ ovs_sbx "test_trunc" ip netns exec client \
+ ping -c 1 -W 2 10.0.0.2 || return 1
+
+ return 0
+}
+
# psample test
# - use psample to observe packets
test_psample() {
--
2.54.0
^ permalink raw reply related
* [PATCH net-next v4] selftests/net/openvswitch: add ICMPv6 echo type match test
From: Minxi Hou @ 2026-07-02 7:50 UTC (permalink / raw)
To: netdev
Cc: Minxi Hou, aconole, echaudro, i.maximets, davem, edumazet, kuba,
pabeni, horms, shuah, dev, linux-kselftest
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>
---
.../selftests/net/openvswitch/openvswitch.sh | 70 +++++++++++++++++++
.../selftests/net/openvswitch/ovs-dpctl.py | 26 +++++--
2 files changed, 89 insertions(+), 7 deletions(-)
diff --git a/tools/testing/selftests/net/openvswitch/openvswitch.sh b/tools/testing/selftests/net/openvswitch/openvswitch.sh
index 2954245129a2..f88cefa71559 100755
--- a/tools/testing/selftests/net/openvswitch/openvswitch.sh
+++ b/tools/testing/selftests/net/openvswitch/openvswitch.sh
@@ -32,6 +32,7 @@ tests="
dec_ttl ttl: dec_ttl decrements IP TTL
flow_set flow-set: Flow modify
action_set set: SET action rewrites fields
+ icmpv6 icmpv6: ICMPv6 echo type match
psample psample: Sampling packets with psample"
info() {
@@ -443,6 +444,75 @@ test_action_set() {
return 0
}
+# icmpv6 test
+# - static neighbours to bypass NDP (nud permanent)
+# - icmpv6(type=128) echo request, icmpv6(type=129) echo reply
+# - remove flows and verify ping fails, reinstall and recover
+test_icmpv6() {
+ local t="test_icmpv6"
+ local v6="eth_type(0x86dd),ipv6(proto=58)"
+
+ sbx_add "$t" || return $?
+ ovs_add_dp "$t" icmpv6 || return 1
+
+ info "create namespaces"
+ for ns in client server; do
+ ovs_add_netns_and_veths "$t" "icmpv6" \
+ "$ns" "${ns:0:1}0" "${ns:0:1}1" || return 1
+ done
+
+ ip netns exec client ip addr add fd00::1/64 dev c1 nodad
+ ip netns exec client ip link set c1 up
+ ip netns exec server ip addr add fd00::2/64 dev s1 nodad
+ ip netns exec server ip link set s1 up
+
+ local cl_mac sl_mac
+ cl_mac=$(ip netns exec client ip link show c1 \
+ | awk '/link\/ether/ {print $2}')
+ [ -z "$cl_mac" ] && \
+ { info "failed to get c1 hwaddr"; return 1; }
+ sl_mac=$(ip netns exec server ip link show s1 \
+ | awk '/link\/ether/ {print $2}')
+ [ -z "$sl_mac" ] && \
+ { info "failed to get s1 hwaddr"; return 1; }
+ ip netns exec client ip -6 neigh add fd00::2 \
+ lladdr "$sl_mac" nud permanent dev c1 || return 1
+ ip netns exec server ip -6 neigh add fd00::1 \
+ lladdr "$cl_mac" nud permanent dev s1 || return 1
+
+ ovs_add_flow "$t" icmpv6 \
+ "in_port(1),eth(),$v6,icmpv6(type=128)" \
+ '2' || return 1
+ ovs_add_flow "$t" icmpv6 \
+ "in_port(2),eth(),$v6,icmpv6(type=129)" \
+ '1' || return 1
+
+ info "verify ICMPv6 echo with type-specific flows"
+ ovs_sbx "$t" ip netns exec client \
+ ping -6 -c 1 -W 2 fd00::2 || return 1
+
+ ovs_del_flows "$t" icmpv6
+
+ info "verify ping fails without echo flows"
+ ovs_sbx "$t" ip netns exec client \
+ ping -6 -c 1 -W 2 fd00::2 >/dev/null 2>&1 \
+ && { info "ping should fail without flows"
+ return 1; }
+
+ ovs_add_flow "$t" icmpv6 \
+ "in_port(1),eth(),$v6,icmpv6(type=128)" \
+ '2' || return 1
+ ovs_add_flow "$t" icmpv6 \
+ "in_port(2),eth(),$v6,icmpv6(type=129)" \
+ '1' || return 1
+
+ info "verify connectivity restored"
+ ovs_sbx "$t" ip netns exec client \
+ ping -6 -c 1 -W 2 fd00::2 || return 1
+
+ return 0
+}
+
# psample test
# - use psample to observe packets
test_psample() {
diff --git a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py
index e1ecfad2c03e..f3edd198223f 100644
--- a/tools/testing/selftests/net/openvswitch/ovs-dpctl.py
+++ b/tools/testing/selftests/net/openvswitch/ovs-dpctl.py
@@ -1255,11 +1255,16 @@ class ovskey(nla):
lambda x: ipaddress.IPv6Address(x).packed if x else 0,
convert_ipv6,
),
- ("label", "label", "%d", lambda x: int(x) if x else 0),
- ("proto", "proto", "%d", lambda x: int(x) if x else 0),
- ("tclass", "tclass", "%d", lambda x: int(x) if x else 0),
- ("hlimit", "hlimit", "%d", lambda x: int(x) if x else 0),
- ("frag", "frag", "%d", lambda x: int(x) if x else 0),
+ ("label", "label", "%d", lambda x: int(x) if x else 0,
+ convert_int(20)),
+ ("proto", "proto", "%d", lambda x: int(x) if x else 0,
+ convert_int(8)),
+ ("tclass", "tclass", "%d", lambda x: int(x) if x else 0,
+ convert_int(8)),
+ ("hlimit", "hlimit", "%d", lambda x: int(x) if x else 0,
+ convert_int(8)),
+ ("frag", "frag", "%d", lambda x: int(x) if x else 0,
+ convert_int(8)),
)
def __init__(
@@ -1344,8 +1349,10 @@ class ovskey(nla):
)
fields_map = (
- ("type", "type", "%d", lambda x: int(x) if x else 0),
- ("code", "code", "%d", lambda x: int(x) if x else 0),
+ ("type", "type", "%d", lambda x: int(x) if x else 0,
+ convert_int(8)),
+ ("code", "code", "%d", lambda x: int(x) if x else 0,
+ convert_int(8)),
)
def __init__(
@@ -1982,6 +1989,11 @@ class ovskey(nla):
"icmp",
ovskey.ovs_key_icmp,
),
+ (
+ "OVS_KEY_ATTR_ICMPV6",
+ "icmpv6",
+ ovskey.ovs_key_icmpv6,
+ ),
(
"OVS_KEY_ATTR_TCP_FLAGS",
"tcp_flags",
--
2.54.0
^ permalink raw reply related
* Re: [PATCH net-next V4 4/6] devlink: Apply eswitch mode boot defaults
From: Jiri Pirko @ 2026-07-02 7:52 UTC (permalink / raw)
To: Mark Bloch
Cc: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Saeed Mahameed, Leon Romanovsky, Tariq Toukan, Andrew Lunn,
Jonathan Corbet, Shuah Khan, netdev, linux-rdma, linux-doc
In-Reply-To: <ecaeeef0-c463-4f10-885a-02ad2d648be0@nvidia.com>
Wed, Jul 01, 2026 at 07:42:57PM +0200, mbloch@nvidia.com wrote:
>
>
>On 01/07/2026 17:09, Jiri Pirko wrote:
>> Wed, Jul 01, 2026 at 02:57:21PM +0200, mbloch@nvidia.com wrote:
>>>
>>>
>>> On 01/07/2026 12:48, Jiri Pirko wrote:
>>>> Mon, Jun 29, 2026 at 08:20:59PM +0200, mbloch@nvidia.com wrote:
>>>>> Apply parsed devlink_eswitch_mode= defaults after devlink registration
>>>>> and after successful reload.
>>>>>
>>>>> devl_register() may still be called before the device is ready for an
>>>>
>>>> How so? I would assume that driver calls devl_register only after
>>>> everything is up and running and ready. If not, isn't it a bug?
>>>>
>>>
>>> You would think so :)
>>>
>>> Some drivers, mlx5 included, call devl_register() while holding the
>>> devlink instance lock and then finish setting up state before releasing
>>> the lock.
>>>
>>> In v3 I tried to enforce exactly that model, move devl_register() to
>>> be the last thing the driver does. Jakub pushed back on making that a
>>> general rule. So in v4 I changed the approach. devl_register() only
>>> schedules the work, and the actual eswitch mode change can run only
>>> after the driver releases the devlink lock.
>>
>> Wouldn't it make sense to use a completion instead of loop-reschedule of
>> delayed work?
>
>Just to make sure I understand the suggestion, this would mean that the
>work waits until the devlink lock holder drops the lock, and devl_unlock()
>would signal it, something like:
>
>void devl_unlock(struct devlink *devlink)
>{
> ool complete_apply = devlink->default_esw_mode_apply_pending;
>
> mutex_unlock(&devlink->lock);
>
> if (complete_apply)
> complete(&devlink->default_esw_mode_apply_ready);
>}
>
>That would avoid the retry loop, but it also means the queued work
>sleeps until the driver drops devl_lock. It does keep one worker
>blocked per pending instance and adds this default-esw-mode signalling to
>the generic devl_unlock() path.
>
>The delayed retry was meant to avoid a sleeping worker and keep the
>instances independent. If one devlink instance is still locked, we just
>try it again later while other instances can progress.
>
>If you prefer the completion approach I can switch to it, but I don't see
>it as simpler overall.
Yeah, I don't have preference. I was just wondering. Feel free to leave
it as is.
Maybe, instead of "complete", you can schedule with "0" delay in
devl_unlock? Well, it does not really need to be delayed work, right?
The only single schedule may be done from devl_unlock. That would help
to eliminate the rescheduling. Am I missing something?
>
>Mark
>
>>
>>>
>>> Mark
>>>
>>>>
>>>>> eswitch mode change, so keep a per-devlink delayed work item and pending
>>>>> flag for the registration path. Registration queues the work, and the
>>>>> worker tries to take the devlink instance lock.
>>>>>
>>>>> If the lock is busy, the worker requeues itself with a delay.
>>>>>
>>>>> For successful reloads that performed DRIVER_REINIT, devlink_reload()
>>>>> already holds the devlink instance lock and the driver has completed
>>>>> reload_up(). Clear pending work and apply the default directly from the
>>>>> reload path instead of queueing work.
>>>>>
>>>>> If a user sets eswitch mode through netlink before the pending
>>>>> registration work runs, clear the pending flag so the queued default does
>>>>> not override that user request. Cancel pending default apply work when
>>>>> freeing the devlink instance.
>>>>
>>>> These AI generated code descriptive messages are generally not very
>>>> useful :(
>>>>
>>>
>
^ permalink raw reply
* RE: [PATCH] net/sched: cake: reject overhead values that underflow length
From: Jagielski, Jedrzej @ 2026-07-02 7:52 UTC (permalink / raw)
To: Samuel Moelius, Toke Høiland-Jørgensen
Cc: Hadi Salim, Jamal, Jiri Pirko, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman,
moderated list:CAKE QDISC, open list:TC subsystem, open list
In-Reply-To: <20260701235656.296208.68e320e0746d.cake-overhead-underflow@trailofbits.com>
From: Samuel Moelius <sam.moelius@trailofbits.com>
Sent: Thursday, July 2, 2026 1:57 AM
>CAKE accepts signed overhead values and stores them in an s16, but the
>adjusted packet length calculation uses unsigned arithmetic. A negative
>effective length can therefore wrap to a large value.
>
>Such configurations make rate accounting depend on integer wraparound
>rather than on the packet size userspace intended to model. A static
>netlink lower bound is not enough because packets reaching CAKE can be
>smaller than any reasonable manual-overhead allowance.
>
>Fold the signed overhead adjustment into the existing datapath MPU clamp
>so negative adjusted lengths are clamped before link-layer framing
>adjustments.
>
>Fixes: a729b7f0bd5b ("sch_cake: Add overhead compensation support to the rate shaper")
>Assisted-by: Codex:gpt-5.5-cyber-preview
>Signed-off-by: Samuel Moelius <sam.moelius@trailofbits.com>
>---
>Changes in v3:
> - Adjust how check is performed
>Changes in v2:
> - Add fixes tag
Hi,
just for the future - please mention the revision number in the
mail subject
^ permalink raw reply
* Re: [PATCH net-next v4 09/15] bnxt_en: Add infrastructure for crypto key context IDs
From: Paolo Abeni @ 2026-07-02 7:53 UTC (permalink / raw)
To: Michael Chan, davem
Cc: netdev, edumazet, kuba, andrew+netdev, pavan.chebbi,
andrew.gospodarek
In-Reply-To: <20260629184921.3496727-10-michael.chan@broadcom.com>
On 6/29/26 8:49 PM, Michael Chan wrote:
> +/**
> + * bnxt_clear_crypto - Clear all crypto key contexts
> + * @bp: pointer to bnxt device
> + *
> + * Clears all key context allocations during shutdown or firmware reset.
> + * Frees all key info structures and bitmaps, and increments the epoch
> + * counter to invalidate any outstanding key references.
> + *
> + * This function assumes serialization (called during shutdown) and does
> + * not use locking.
> + *
> + * Context: Process context during shutdown/reset
> + */
> +void bnxt_clear_crypto(struct bnxt *bp)
> +{
> + struct bnxt_crypto_info *crypto = bp->crypto_info;
> + struct bnxt_kid_info *kid, *tmp;
> + struct bnxt_kctx *kctx;
> + int i;
> +
> + if (!crypto)
> + return;
> +
> + /* Only called when shutting down or FW reset with BNXT_STATE_OPEN
> + * cleared, so no concurrent access. No protection needed.
> + */
> + for (i = 0; i < BNXT_MAX_CRYPTO_KEY_TYPE; i++) {
> + kctx = &crypto->kctx[i];
> + list_for_each_entry_safe(kid, tmp, &kctx->list, list) {
> + list_del(&kid->list);
> + kfree(kid);
Sashiko still complains about RCU rules violation here, and the complain
looks legit to me.
Note that to streamline patch processing you are expected to reply to
sashiko comments outline why they are (not) legit.
/P
^ permalink raw reply
* Re: [PATCH net-next v4 15/15] bnxt_en: Add kTLS retransmission support
From: Paolo Abeni @ 2026-07-02 7:55 UTC (permalink / raw)
To: Michael Chan, davem
Cc: netdev, edumazet, kuba, andrew+netdev, pavan.chebbi,
andrew.gospodarek
In-Reply-To: <20260629184921.3496727-16-michael.chan@broadcom.com>
On 6/29/26 8:49 PM, Michael Chan wrote:
> int bnxt_ktls_alloc_tx_ring_stats(struct bnxt *bp, struct bnxt_tx_ring_info *txr)
> diff --git a/drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.h b/drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.h
> index 1c935e0d413d..40b94bbf5a38 100644
> --- a/drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.h
> +++ b/drivers/net/ethernet/broadcom/bnxt/bnxt_ktls.h
> @@ -43,6 +43,8 @@ struct bnxt_ktls_offload_ctx_tx {
> u32 next_tcp_seq_no;/* staged tcp seq no */
> u32 kid;
> u32 pending_bytes; /* staged payload bytes */
> + u32 pending_fwd:1;
> + u32 pending_ooo:1;
Minor nit: AFAICS the above field are touched in fastpath. Using a
`bool` type will likely yield better code.
/P
^ permalink raw reply
* Re: [REGRESSION][BISECTED] tun/tap & vhost-net: multi-threaded network performance
From: Simon Schippers @ 2026-07-02 8:01 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Brett Sheffield, regressions, netdev, Jakub Kicinski, Tim Gebauer,
Willem de Bruijn, Jason Wang, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, linux-kernel
In-Reply-To: <20260702034152-mutt-send-email-mst@kernel.org>
On 7/2/26 09:42, Michael S. Tsirkin wrote:
> On Thu, Jul 02, 2026 at 09:24:59AM +0200, Simon Schippers wrote:
>> On 7/1/26 22:56, Michael S. Tsirkin wrote:
>>> On Wed, Jul 01, 2026 at 09:16:48PM +0200, Brett Sheffield wrote:
>>>> TL;DR - Commit 1d6e569b7d0c0b2736636749e4be0a27f3cefcb3 causes
>>>> significant performance regressions with TAP interfaces and multithreaded
>>>> network code. Please revert.
>>>>
>>>>
>>>> Librecast is an IPv6 multicast library. One of the tests (0055) fails under
>>>> Linux 7.2-rc1. The test performs data synchronization over IPv6 multicast using a TAP
>>>> interface. This test has run successfully on every stable, LTS and mainline RC
>>>> released in the past year. Every kernel with my Tested-by has run this test.
>>>>
>>>> There have been a bunch of changes to MLDv2 so I started bisecting there, but
>>>> the culprit is actually 1d6e569b7d0c0b2736636749e4be0a27f3cefcb3 "tun/tap &
>>>> vhost-net: avoid ptr_ring tail-drop when a qdisc is present"
>>>>
>>>> Reverting this commit fixes the test.
>>>>
>>>> To eliminate my code and any multicast weirdness, I ran tests with iperf3
>>>> comparing the same host running 7.2-rc1 both with and without 1d6e569b7d0
>>>> reverted.
>>
>> Thank you very much for your bisect!
>>
>> As the author, I am sorry for that regression!
>>
>>>
>>> Thanks a lot for the bisect! Reverting is not out of question, but
>>> just before we do, it is worth analyzing the situation.
>>>
>>> Could you pls tell us
>>> - do you see packet drops?
>>
>> iperf3 shows no TCP retransmissions, so there were never packet drops
>> when the patch was enabled.
>> It is the number after the sender data rate (example: threads 1,
>> reverted has 368 retransmissions/drops).
>>
>>> - does it help to increase the tun queue size?
>>
>> I agree, this would be great to know.
>>
>> However, even then we must act. I am considering IFF_BACKPRESSURE
>> as a feature flag, defaulting to off. It would just enable/disable
>> the stopping logic in tun_net_xmit() and the waking logic
>> in __tun_wake_queue(). If disabled, it would result in the same logic
>> as before.
>>
>> I could provide such a patch as [net] material.
>>
>> Thanks again!
>
> Or BQL? I quickly wrote a prototype of that and it seems to work well -
> could you help test maybe?
BQL won't fix it I think.
A bigger TUN queue would probably fix it but BQL can only just adjust
to a smaller queue than 500 packets.
Unless you don't take the ptr_ring size as an upper limit for BQL and
resize the ptr_ring on the fly? I don't think this is viable.
I am currently working with others to get BQL working for veth.
TLDR: The issue with software interfaces is that there is no *periodic*
completion process [2]. For hardware there is.
I applied the same veth approach for TUN and it showed to fix
bufferbloat... But again won't fix the issue here I think.
[1] Link: https://lore.kernel.org/netdev/20260612083530.1650245-1-hawk@kernel.org/T/#u
[2] Link: https://lwn.net/Articles/469651/
>
>
>>>
>>> Thanks a lot!
>>>
>>>
>>>> CPU: AMD Ryzen 9 9950X
This processor has 2 CCDs. This probably makes the issue worse then it
was for me. My (older) Ryzen 5 5600X only has a single CCD.
Thanks.
>>>>
>>>> [ host ] - [ bridge ] - [ tap ] - [ guest (qemu) ]
>>>>
>>>> Running matching kernels on host and guest, I started iperf3 in server mode on
>>>> the guest and tested from the host so traffic passes through the tap interface.
>>>>
>>>> iperf3 -s -V # server
>>>> iperf3 -c guest -P nthreads # client
>>>>
>>>> 7.2.0-rc1 (threads 1):
>>>>
>>>> [ 5] 0.00-10.00 sec 20.2 GBytes 17.4 Gbits/sec 0 sender
>>>> [ 5] 0.00-10.00 sec 2.00 GBytes 1.72 Gbits/sec receiver
>>>>
>>>> 7.2.0-rc1 (threads 1, reverted):
>>>>
>>>> [ 5] 0.00-10.00 sec 15.3 GBytes 13.1 Gbits/sec 368 sender
>>>> [ 5] 0.00-10.00 sec 2.00 GBytes 1.72 Gbits/sec receiver
>>>>
>>>> 7.2.0-rc1 (threads 2):
>>>>
>>>> [SUM] 0.00-10.00 sec 10.9 GBytes 9.33 Gbits/sec 0 sender
>>>> [SUM] 0.00-10.00 sec 4.00 GBytes 3.43 Gbits/sec receiver
>>>>
>>>> 7.2.0-rc1 (threads 2, reverted):
>>>>
>>>> [SUM] 0.00-10.00 sec 15.9 GBytes 13.7 Gbits/sec 1567 sender
>>>> [SUM] 0.00-10.00 sec 4.00 GBytes 3.43 Gbits/sec receiver
>>>>
>>>> 7.2.0-rc1 (threads 4):
>>>>
>>>> [SUM] 0.00-10.00 sec 10.9 GBytes 9.33 Gbits/sec 0 sender
>>>> [SUM] 0.00-10.00 sec 8.00 GBytes 6.87 Gbits/sec receiver
>>>>
>>>> 7.2.0-rc1 (threads 4, reverted):
>>>>
>>>> [SUM] 0.00-10.00 sec 16.5 GBytes 14.1 Gbits/sec 6701 sender
>>>> [SUM] 0.00-10.00 sec 8.00 GBytes 6.87 Gbits/sec receiver
>>>>
>>>> 7.2.0-rc1 (threads 8):
>>>>
>>>> [SUM] 0.00-10.00 sec 10.7 GBytes 9.15 Gbits/sec 0 sender
>>>> [SUM] 0.00-10.01 sec 10.6 GBytes 9.13 Gbits/sec receiver
>>>>
>>>> 7.2.0-rc1 (threads 8, reverted):
>>>>
>>>> [SUM] 0.00-10.00 sec 16.2 GBytes 14.0 Gbits/sec 19319 sender
>>>> [SUM] 0.00-10.00 sec 15.7 GBytes 13.5 Gbits/sec receiver
>>>>
>>>> 7.2.0-rc1 (threads 16):
>>>>
>>>> [SUM] 0.00-10.00 sec 10.9 GBytes 9.35 Gbits/sec 0 sender
>>>> [SUM] 0.00-10.01 sec 10.9 GBytes 9.32 Gbits/sec receiver
>>>>
>>>> 7.2.0-rc1 (threads 16, reverted):
>>>>
>>>> [SUM] 0.00-10.00 sec 14.4 GBytes 12.4 Gbits/sec 43593 sender
>>>> [SUM] 0.00-10.00 sec 14.4 GBytes 12.4 Gbits/sec receiver
>>>>
>>>>
>>>> As you can see, the new code works for single threaded, but for all other cases
>>>> there's a significant performance drop. I see this trade-off is mentioned in the
>>>> commit, but the performance drop off is much worse than suggested with the
>>>> current patch.
>>>>
>>>> In our multicast use case data is sent by multiple threads to multiple groups
>>>> simultaneously, this just breaks things to the extent that a <2 second test
>>>> times out after 5 minutes.
>>>>
>>>>
>>>> git bisect start
>>>> # status: waiting for both good and bad commits
>>>> # bad: [dc59e4fea9d83f03bad6bddf3fa2e52491777482] Linux 7.2-rc1
>>>> git bisect bad dc59e4fea9d83f03bad6bddf3fa2e52491777482
>>>> # status: waiting for good commit(s), bad commit known
>>>> # good: [36bdc0e815b4e8a05b9028d8ef8a25e1ead35cc1] net: usb: asix: ax88772: re-add usbnet_link_change() in phylink callbacks
>>>> git bisect good 36bdc0e815b4e8a05b9028d8ef8a25e1ead35cc1
>>>> # good: [db314398f618a3a23315f73c87f7d318eaf06c1b] Merge branch 'net-bridge-mcast-support-exponential-field-encoding'
>>>> git bisect good db314398f618a3a23315f73c87f7d318eaf06c1b
>>>> # bad: [079a028d6327e68cfa5d38b36123637b321c19a7] string: Remove strncpy() from the kernel
>>>> git bisect bad 079a028d6327e68cfa5d38b36123637b321c19a7
>>>> # bad: [f396f4005180928cd9e15e352a6512865d3bc908] Bluetooth: btmtk: fix URB leak in alloc_mtk_intr_urb error path
>>>> git bisect bad f396f4005180928cd9e15e352a6512865d3bc908
>>>> # bad: [ec1806a730a1c0b3d68a7f9afe81514fb0dd7991] netfilter: x_tables: disable 32bit compat interface in user namespaces
>>>> git bisect bad ec1806a730a1c0b3d68a7f9afe81514fb0dd7991
>>>> # good: [50c2d91c5dfa0e465826ec1f8dbad9cdc254bd85] mptcp: do not drop partial packets
>>>> git bisect good 50c2d91c5dfa0e465826ec1f8dbad9cdc254bd85
>>>> # good: [68993ced0f618e36cf33388f1e50223e5e6e78cc] Merge tag 'net-7.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net
>>>> git bisect good 68993ced0f618e36cf33388f1e50223e5e6e78cc
>>>> # good: [34c78dff59a25110a4ce50c208e42a91490fe615] Merge branch 'net-use-ip_outnoroutes-drop-reason'
>>>> git bisect good 34c78dff59a25110a4ce50c208e42a91490fe615
>>>> # bad: [9587ed8137fb83d93f84b858337412f4500b21e9] Merge branch 'gve-add-support-for-ptp-gettimex64'
>>>> git bisect bad 9587ed8137fb83d93f84b858337412f4500b21e9
>>>> # bad: [83ea7fd73b11dd8cbf4416507a5eac3890b49fb0] net: dsa: microchip: remove unused phylink_mac_link_up() callback
>>>> git bisect bad 83ea7fd73b11dd8cbf4416507a5eac3890b49fb0
>>>> # bad: [f0de88303d5e7e04a1224bc7a00512b5a1c4fe7a] net: make is_skb_wmem() available to modules
>>>> git bisect bad f0de88303d5e7e04a1224bc7a00512b5a1c4fe7a
>>>> # bad: [c411baa463e85a779a7e68a00ba6298770b58c4c] netconsole: move push_ipv6() from netpoll
>>>> git bisect bad c411baa463e85a779a7e68a00ba6298770b58c4c
>>>> # good: [fba362c17d9d9211fc51f272156bb84fc23bdf98] ptr_ring: move free-space check into separate helper
>>>> git bisect good fba362c17d9d9211fc51f272156bb84fc23bdf98
>>>> # bad: [d0273dbe8be1640e597552f81faf1d6c9997d3e3] ipvlan: use netif_receive_skb() in ipvlan_process_multicast()
>>>> git bisect bad d0273dbe8be1640e597552f81faf1d6c9997d3e3
>>>> # bad: [3803065cd6b0630d4161d86aa04e2d1db0f3a0b5] Merge branch 'tun-tap-vhost-net-apply-qdisc-backpressure-on-full-ptr_ring-to-reduce-tx-drops'
>>>> git bisect bad 3803065cd6b0630d4161d86aa04e2d1db0f3a0b5
>>>> # bad: [1d6e569b7d0c0b2736636749e4be0a27f3cefcb3] tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present
>>>> git bisect bad 1d6e569b7d0c0b2736636749e4be0a27f3cefcb3
>>>> # first bad commit: [1d6e569b7d0c0b2736636749e4be0a27f3cefcb3] tun/tap & vhost-net: avoid ptr_ring tail-drop when a qdisc is present
>>>>
>>>> --
>>>> Brett Sheffield (he/him)
>>>> Librecast - Decentralising the Internet with Multicast
>>>> https://librecast.net/
>>>> https://blog.brettsheffield.com/
>>>
>
^ permalink raw reply
* Re: [PATCH net-next 1/3] net: ipv4: report multicast group user count
From: Ido Schimmel @ 2026-07-02 8:11 UTC (permalink / raw)
To: Yuyang Huang
Cc: David S. Miller, Andrew Lunn, David Ahern, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Shuah Khan,
Simon Horman, linux-kernel, linux-kselftest, netdev
In-Reply-To: <20260630110207.37841-2-sigefriedhyy@gmail.com>
On Tue, Jun 30, 2026 at 08:02:05PM +0900, Yuyang Huang wrote:
> RTM_GETMULTICAST has been part of the rtnetlink ABI for a long time
> and already reports IPv4 multicast group membership through
> IFA_MULTICAST and IFA_CACHEINFO. It does not report how many consumers
> hold each membership, so userspace still has to parse /proc/net/igmp to
> get the Users column.
>
> Add IFA_MC_USERS as a u32 attribute carrying ip_mc_list::users in
> RTM_GETMULTICAST replies and entry-lifecycle notifications.
>
> This gives iproute2 enough information to migrate the IPv4 part of
> "ip maddr show" from procfs parsing to rtnetlink.
>
> Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
^ permalink raw reply
* Re: [PATCH net-next 2/3] net: ipv6: report multicast group user count
From: Ido Schimmel @ 2026-07-02 8:12 UTC (permalink / raw)
To: Yuyang Huang
Cc: David S. Miller, Andrew Lunn, David Ahern, Donald Hunter,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Shuah Khan,
Simon Horman, linux-kernel, linux-kselftest, netdev
In-Reply-To: <20260630110207.37841-3-sigefriedhyy@gmail.com>
On Tue, Jun 30, 2026 at 08:02:06PM +0900, Yuyang Huang wrote:
> The previous patch added IFA_MC_USERS and emits it for IPv4 multicast
> groups. Add the same snapshot attribute to IPv6 RTM_GETMULTICAST
> replies and entry-lifecycle notifications, carrying
> ifmcaddr6::mca_users.
>
> This makes the multicast rtnetlink ABI symmetric across IPv4 and IPv6
> and gives userspace the same user count that /proc/net/igmp6 exposes.
>
> Signed-off-by: Yuyang Huang <sigefriedhyy@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
^ permalink raw reply
* Re: [PATCH net v2 2/2] pds_core: fix use-after-free on workqueue during remove
From: Paolo Abeni @ 2026-07-02 8:13 UTC (permalink / raw)
To: Nikhil P. Rao, netdev
Cc: kuba, brett.creeley, eric.joyner, andrew+netdev, davem, edumazet
In-Reply-To: <20260629200358.2626129-3-nikhil.rao@amd.com>
On 6/29/26 10:03 PM, Nikhil P. Rao wrote:
> In pdsc_remove(), the workqueue is destroyed before pdsc_teardown()
> is called. This ordering allows two paths to queue work on the
> destroyed workqueue:
>
> 1. If pdsc_teardown() -> pdsc_devcmd_reset() times out, the error
> path in pdsc_devcmd_locked() queues health_work.
>
> 2. A NotifyQ event can trigger the ISR and queue work before free_irq()
> is called in pdsc_teardown().
I think this should be 2 separate patches.
> @@ -121,10 +122,16 @@ void pdsc_process_adminq(struct pdsc_qcq *qcq)
> qcq->accum_work += aq_work;
>
> credits:
> - /* Return the interrupt credits, one for each completion */
> - pds_core_intr_credits(&pdsc->intr_ctrl[qcq->intx],
> - nq_work + aq_work,
> - PDS_CORE_INTR_CRED_REARM);
> + /* Return the interrupt credits, one for each completion.
> + * Use READ_ONCE to get a single consistent copy of intx since it can
> + * be set to PDS_CORE_INTR_INDEX_NOT_ASSIGNED concurrently during
> + * teardown, and skip the credits if so.
> + */
> + intx = READ_ONCE(qcq->intx);
> + if (intx != PDS_CORE_INTR_INDEX_NOT_ASSIGNED)
> + pds_core_intr_credits(&pdsc->intr_ctrl[intx],
> + nq_work + aq_work,
> + PDS_CORE_INTR_CRED_REARM);
AFAICS this does not look safe.
A concurrent pdsc_qcq_free()/pdsc_qcq_intr_free() may free
`pdsc->intr_ctrl` before setting PDS_CORE_INTR_INDEX_NOT_ASSIGNED.
I think the teardown should:
- disable the IRQ
- cancel the work
- free the structs
in the above sequence.
/P
^ permalink raw reply
* Re: [PATCH net v2] ppp: defer channel free to an RCU grace period to fix pppol2tp RX UAF
From: Qingfang Deng @ 2026-07-02 8:19 UTC (permalink / raw)
To: Norbert Szetei
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Sebastian Andrzej Siewior, Breno Leitao, Taegu Ha,
Kees Cook, linux-ppp, linux-kernel, Guillaume Nault, netdev
In-Reply-To: <D9C0245B-608B-4884-8A09-F55BA4A9F948@doyensec.com>
Add: Guillaume
On 2026/7/2 at 2:12, Norbert Szetei wrote:
> pppol2tp_recv() runs in the L2TP UDP-encap softirq RX path:
>
> l2tp_udp_encap_recv() -> l2tp_recv_common() -> pppol2tp_recv()
> -> ppp_input(&po->chan)
>
> It runs under rcu_read_lock() holding only an l2tp_session reference and
> takes NO reference on the internal PPP channel (struct channel,
> chan->ppp) that ppp_input() dereferences.
>
> The pppox socket is SOCK_RCU_FREE, so 'po' and the embedded ppp_channel
> are RCU-safe. But the internal struct channel is a separate allocation
> that ppp_release_channel() frees with a plain kfree():
>
> close(data socket) -> pppol2tp_release() -> pppox_unbind_sock()
> -> ppp_unregister_channel() -> ppp_release_channel() -> kfree(pch)
>
> For a channel that is bound (PPPIOCGCHAN) but not attached to a ppp unit
> (no PPPIOCCONNECT, pch->ppp == NULL) and not bridged, teardown skips
> both ppp_disconnect_channel()'s synchronize_net() and
> ppp_unbridge_channels()'s synchronize_rcu(), so the kfree() has no grace
> period. rcu_read_lock() in pppol2tp_recv() does not protect against a
> plain kfree(), so an in-flight ppp_input() on one CPU can dereference
> the channel just freed by close() on another CPU.
>
> The bug is reachable by an unprivileged user.
>
> Defer the channel free to an RCU callback via call_rcu() so the grace
> period fences any in-flight ppp_input(). The disconnect and unbridge
> teardown paths already fence with synchronize_net()/synchronize_rcu();
> call_rcu() does the same here without stalling the close() path.
>
> Fixes: ee40fb2e1eb5 ("l2tp: protect sock pointer of struct pppol2tp_session with RCU")
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Norbert Szetei <norbert@doyensec.com>
> ---
> v2:
> - Moved skb_queue_purge() to a dedicated RCU callback to prevent leaking
> skbs added by an in-flight ppp_input() during the grace period (Sebastian).
> - Retained call_rcu() to avoid introducing synchronous multi-millisecond
> latency into the teardown path.
> v1: https://lore.kernel.org/netdev/C954A7EA-AA98-4E3C-80B5-42C34B3183A3@doyensec.com/
>
> drivers/net/ppp/ppp_generic.c | 17 ++++++++++++++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ppp/ppp_generic.c b/drivers/net/ppp/ppp_generic.c
> index 57c68efa5ff8..2d57de77780f 100644
> --- a/drivers/net/ppp/ppp_generic.c
> +++ b/drivers/net/ppp/ppp_generic.c
> @@ -184,6 +184,7 @@ struct channel {
> struct list_head clist; /* link in list of channels per unit */
> spinlock_t upl; /* protects `ppp' and 'bridge' */
> struct channel __rcu *bridge; /* "bridged" ppp channel */
> + struct rcu_head rcu; /* for RCU-deferred free of the channel */
> #ifdef CONFIG_PPP_MULTILINK
> u8 avail; /* flag used in multilink stuff */
> u8 had_frag; /* >= 1 fragments have been sent */
> @@ -3562,6 +3563,18 @@ ppp_disconnect_channel(struct channel *pch)
> return err;
> }
>
> +/* Purge after the grace period: a late ppp_input() may still queue an
> + * skb on pch->file.rq before the last RCU reader drains.
> + */
> +static void ppp_release_channel_free(struct rcu_head *rcu)
> +{
> + struct channel *pch = container_of(rcu, struct channel, rcu);
> +
> + skb_queue_purge(&pch->file.xq);
> + skb_queue_purge(&pch->file.rq);
> + kfree(pch);
> +}
> +
> /*
> * Drop a reference to a ppp channel and free its memory if the refcount reaches
> * zero.
> @@ -3581,9 +3594,7 @@ static void ppp_release_channel(struct channel *pch)
> pr_err("ppp: destroying undead channel %p !\n", pch);
> return;
> }
> - skb_queue_purge(&pch->file.xq);
> - skb_queue_purge(&pch->file.rq);
> - kfree(pch);
> + call_rcu(&pch->rcu, ppp_release_channel_free);
> }
>
> static void __exit ppp_cleanup(void)
Reviewed-by: Qingfang Deng <qingfang.deng@linux.dev>
FYI, I attempted to merge the two channel structs and AI-review found a
UAF [1], so this patch addresses the issue.
[1]
https://lore.kernel.org/netdev/590d7931-02b0-45d6-8f43-ef909c9bde89@redhat.com/
Best regards,
Qingfang
^ 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