* RE: [Intel-wired-lan] [PATCH iwl-next v1 1/2] igb: use napi_schedule_irqoff() instead of napi_schedule()
From: Loktionov, Aleksandr @ 2026-04-01 7:52 UTC (permalink / raw)
To: Daiki Harada, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Nguyen, Anthony L, Kitszel, Przemyslaw, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Kohei Enju
In-Reply-To: <20260331103924.36422-2-daiky0325@gmail.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Daiki Harada
> Sent: Tuesday, March 31, 2026 12:39 PM
> To: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric
> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>; Daiki Harada <daiky0325@gmail.com>; Kohei
> Enju <kohei@enjuk.jp>
> Subject: [Intel-wired-lan] [PATCH iwl-next v1 1/2] igb: use
> napi_schedule_irqoff() instead of napi_schedule()
>
> Replace napi_schedule() with napi_schedule_irqoff() in the interrupt
> handler path in igb driver
>
> Tested on QEMU with igb NIC emulation (-nic user,model=igb)
>
> Suggested-by: Kohei Enju <kohei@enjuk.jp>
> Signed-off-by: Daiki Harada <daiky0325@gmail.com>
> ---
> drivers/net/ethernet/intel/igb/igb_main.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/igb/igb_main.c
> b/drivers/net/ethernet/intel/igb/igb_main.c
> index ee99fd8fd513..d7a6ae938cc5 100644
> --- a/drivers/net/ethernet/intel/igb/igb_main.c
> +++ b/drivers/net/ethernet/intel/igb/igb_main.c
> @@ -7158,7 +7158,7 @@ static irqreturn_t igb_msix_ring(int irq, void
> *data)
> /* Write the ITR value calculated from the previous interrupt.
> */
> igb_write_itr(q_vector);
>
> - napi_schedule(&q_vector->napi);
> + napi_schedule_irqoff(&q_vector->napi);
>
> return IRQ_HANDLED;
> }
> @@ -8199,7 +8199,7 @@ static irqreturn_t igb_intr_msi(int irq, void
> *data)
> if (icr & E1000_ICR_TS)
> igb_tsync_interrupt(adapter);
>
> - napi_schedule(&q_vector->napi);
> + napi_schedule_irqoff(&q_vector->napi);
>
> return IRQ_HANDLED;
> }
> @@ -8245,7 +8245,7 @@ static irqreturn_t igb_intr(int irq, void *data)
> if (icr & E1000_ICR_TS)
> igb_tsync_interrupt(adapter);
>
> - napi_schedule(&q_vector->napi);
> + napi_schedule_irqoff(&q_vector->napi);
>
> return IRQ_HANDLED;
> }
> --
> 2.53.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* Re: [PATCH net-next v03 3/6] hinic3: Add ethtool coalesce ops
From: Mohsin Bashir @ 2026-04-01 7:53 UTC (permalink / raw)
To: Fan Gong, Zhu Yikai, netdev, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Andrew Lunn,
Ioana Ciornei
Cc: linux-kernel, linux-doc, luosifu, Xin Guo, Zhou Shuai, Wu Like,
Shi Jing, Zheng Jiezhen, Maxime Chevallier
In-Reply-To: <ffc357656b2412abf6e8de4200d289e761f3e6ea.1774940117.git.zhuyikai1@h-partners.com>
> +static int is_coalesce_exceed_limit(struct net_device *netdev,
> + const struct ethtool_coalesce *coal)
> +{
> + const struct {
> + const char *name;
> + u32 value;
> + u32 limit;
> + } coalesce_limits[] = {
> + {"rx_coalesce_usecs",
> + coal->rx_coalesce_usecs,
> + COALESCE_MAX_TIMER_CFG},
> + {"rx_max_coalesced_frames",
> + coal->rx_max_coalesced_frames,
> + COALESCE_MAX_PENDING_LIMIT},
> + {"rx_max_coalesced_frames_low",
> + coal->rx_max_coalesced_frames_low,
> + COALESCE_MAX_PENDING_LIMIT},
> + {"rx_max_coalesced_frames_high",
> + coal->rx_max_coalesced_frames_high,
> + COALESCE_MAX_PENDING_LIMIT},
> + };
> +
> + for (int i = 0; i < ARRAY_SIZE(coalesce_limits); i++) {
> + if (coalesce_limits[i].value > coalesce_limits[i].limit) {
> + netdev_err(netdev, "%s out of range %d-%d\n",
> + coalesce_limits[i].name, 0,
> + coalesce_limits[i].limit);
> + return -EOPNOTSUPP;
Since we are failing a range check, maybe -ERANGE or -EINVAL would be
more appropriate here.
> + }
> + }
> + return 0;
> +}
> +
> +static int is_coalesce_legal(struct net_device *netdev,
> + const struct ethtool_coalesce *coal)
> +{
> + int err;
> +
> + err = is_coalesce_exceed_limit(netdev, coal);
> + if (err)
> + return err;
> +
> + if (coal->rx_max_coalesced_frames_low >=
> + coal->rx_max_coalesced_frames_high &&
> + coal->rx_max_coalesced_frames_high > 0) {
So this would allow non-zero low and zero high. For example, low = 10,
high = 0. Is this expected?
> + netdev_err(netdev, "invalid coalesce frame high %u, low %u, unit %d\n",
> + coal->rx_max_coalesced_frames_high,
> + coal->rx_max_coalesced_frames_low,
> + COALESCE_PENDING_LIMIT_UNIT);
> + return -EOPNOTSUPP;
> + }
> +
> + return 0;
> +}
> +
> +static void check_coalesce_align(struct net_device *netdev,
> + u32 item, u32 unit, const char *str)
> +{
> + if (item % unit)
> + netdev_warn(netdev, "%s in %d units, change to %u\n",
> + str, unit, item - item % unit);
> +}
> +
> +#define CHECK_COALESCE_ALIGN(member, unit) \
> + check_coalesce_align(netdev, member, unit, #member)
> +
> +static void check_coalesce_changed(struct net_device *netdev,
> + u32 item, u32 unit, u32 ori_val,
> + const char *obj_str, const char *str)
> +{
> + if ((item / unit) != ori_val)
> + netdev_dbg(netdev, "Change %s from %d to %u %s\n",
> + str, ori_val * unit, item - item % unit, obj_str);
> +}
> +
> +#define CHECK_COALESCE_CHANGED(member, unit, ori_val, obj_str) \
> + check_coalesce_changed(netdev, member, unit, ori_val, obj_str, #member)
> +
> +static int hinic3_set_hw_coal_param(struct net_device *netdev,
> + struct hinic3_intr_coal_info *intr_coal)
> +{
> + struct hinic3_nic_dev *nic_dev = netdev_priv(netdev);
> + int err;
> + u16 i;
> +
> + for (i = 0; i < nic_dev->max_qps; i++) {
> + err = hinic3_set_queue_coalesce(netdev, i, intr_coal);
> + if (err)
> + return err;
> + }
> +
> + return 0;
> +}
> +
> +static int hinic3_get_coalesce(struct net_device *netdev,
> + struct ethtool_coalesce *coal,
> + struct kernel_ethtool_coalesce *kernel_coal,
> + struct netlink_ext_ack *extack)
> +{
> + struct hinic3_nic_dev *nic_dev = netdev_priv(netdev);
> + struct hinic3_intr_coal_info *interrupt_info;
> +
> + interrupt_info = &nic_dev->intr_coalesce[0];
> +
> + /* TX/RX uses the same interrupt.
> + * So we only declare RX ethtool_coalesce parameters.
> + */
> + coal->rx_coalesce_usecs = interrupt_info->coalesce_timer_cfg *
> + COALESCE_TIMER_CFG_UNIT;
> + coal->rx_max_coalesced_frames = interrupt_info->pending_limit *
> + COALESCE_PENDING_LIMIT_UNIT;
> +
> + coal->use_adaptive_rx_coalesce = nic_dev->adaptive_rx_coal;
> +
> + coal->rx_max_coalesced_frames_high =
> + interrupt_info->rx_pending_limit_high *
> + COALESCE_PENDING_LIMIT_UNIT;
> +
> + coal->rx_max_coalesced_frames_low =
> + interrupt_info->rx_pending_limit_low *
> + COALESCE_PENDING_LIMIT_UNIT;
> +
> + return 0;
> +}
> +
> +static int hinic3_set_coalesce(struct net_device *netdev,
> + struct ethtool_coalesce *coal,
> + struct kernel_ethtool_coalesce *kernel_coal,
> + struct netlink_ext_ack *extack)
> +{
> + struct hinic3_nic_dev *nic_dev = netdev_priv(netdev);
> + struct hinic3_intr_coal_info *ori_intr_coal;
> + struct hinic3_intr_coal_info intr_coal = {};
> + char obj_str[32];
> + int err;
> +
> + err = is_coalesce_legal(netdev, coal);
> + if (err)
> + return err;
> +
> + CHECK_COALESCE_ALIGN(coal->rx_coalesce_usecs, COALESCE_TIMER_CFG_UNIT);
> + CHECK_COALESCE_ALIGN(coal->rx_max_coalesced_frames,
> + COALESCE_PENDING_LIMIT_UNIT);
> + CHECK_COALESCE_ALIGN(coal->rx_max_coalesced_frames_high,
> + COALESCE_PENDING_LIMIT_UNIT);
> + CHECK_COALESCE_ALIGN(coal->rx_max_coalesced_frames_low,
> + COALESCE_PENDING_LIMIT_UNIT);
> +
> + ori_intr_coal = &nic_dev->intr_coalesce[0];
> + snprintf(obj_str, sizeof(obj_str), "for netdev");
> +
> + CHECK_COALESCE_CHANGED(coal->rx_coalesce_usecs, COALESCE_TIMER_CFG_UNIT,
> + ori_intr_coal->coalesce_timer_cfg, obj_str);
> + CHECK_COALESCE_CHANGED(coal->rx_max_coalesced_frames,
> + COALESCE_PENDING_LIMIT_UNIT,
> + ori_intr_coal->pending_limit, obj_str);
> + CHECK_COALESCE_CHANGED(coal->rx_max_coalesced_frames_high,
> + COALESCE_PENDING_LIMIT_UNIT,
> + ori_intr_coal->rx_pending_limit_high, obj_str);
> + CHECK_COALESCE_CHANGED(coal->rx_max_coalesced_frames_low,
> + COALESCE_PENDING_LIMIT_UNIT,
> + ori_intr_coal->rx_pending_limit_low, obj_str);
> +
> + intr_coal.coalesce_timer_cfg =
> + (u8)(coal->rx_coalesce_usecs / COALESCE_TIMER_CFG_UNIT);
> + intr_coal.pending_limit = (u8)(coal->rx_max_coalesced_frames /
> + COALESCE_PENDING_LIMIT_UNIT);
> +
> + nic_dev->adaptive_rx_coal = coal->use_adaptive_rx_coalesce;
> +
> + intr_coal.rx_pending_limit_high =
> + (u8)(coal->rx_max_coalesced_frames_high /
> + COALESCE_PENDING_LIMIT_UNIT);
> +
> + intr_coal.rx_pending_limit_low =
> + (u8)(coal->rx_max_coalesced_frames_low /
> + COALESCE_PENDING_LIMIT_UNIT);
> +
> + /* coalesce timer or pending set to zero will disable coalesce */
> + if (!nic_dev->adaptive_rx_coal &&
> + (!intr_coal.coalesce_timer_cfg || !intr_coal.pending_limit))
> + netdev_warn(netdev, "Coalesce will be disabled\n");
> +
> + return hinic3_set_hw_coal_param(netdev, &intr_coal);
> +}
> +
> static const struct ethtool_ops hinic3_ethtool_ops = {
> - .supported_coalesce_params = ETHTOOL_COALESCE_USECS |
> - ETHTOOL_COALESCE_PKT_RATE_RX_USECS,
> + .supported_coalesce_params = ETHTOOL_COALESCE_RX_USECS |
> + ETHTOOL_COALESCE_RX_MAX_FRAMES |
> + ETHTOOL_COALESCE_USE_ADAPTIVE_RX |
> + ETHTOOL_COALESCE_RX_MAX_FRAMES_LOW |
> + ETHTOOL_COALESCE_RX_MAX_FRAMES_HIGH,
Looks like ETHTOOL_COALESCE_TX_USECS support got dropped. is it intentional?
> .get_link_ksettings = hinic3_get_link_ksettings,
> .get_drvinfo = hinic3_get_drvinfo,
> .get_msglevel = hinic3_get_msglevel,
> @@ -1004,6 +1231,8 @@ static const struct ethtool_ops hinic3_ethtool_ops = {
> .get_eth_ctrl_stats = hinic3_get_eth_ctrl_stats,
> .get_rmon_stats = hinic3_get_rmon_stats,
> .get_pause_stats = hinic3_get_pause_stats,
> + .get_coalesce = hinic3_get_coalesce,
> + .set_coalesce = hinic3_set_coalesce,
> };
>
> void hinic3_set_ethtool_ops(struct net_device *netdev)
^ permalink raw reply
* Re: [PATCH net-next v03 4/6] hinic3: Add ethtool rss ops
From: Mohsin Bashir @ 2026-04-01 7:53 UTC (permalink / raw)
To: Fan Gong, Zhu Yikai, netdev, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Andrew Lunn,
Ioana Ciornei
Cc: linux-kernel, linux-doc, luosifu, Xin Guo, Zhou Shuai, Wu Like,
Shi Jing, Zheng Jiezhen, Maxime Chevallier
In-Reply-To: <a8347921a7ac11ca7e0db52381be70689b830005.1774940117.git.zhuyikai1@h-partners.com>
> /* hilink mac group command */
> diff --git a/drivers/net/ethernet/huawei/hinic3/hinic3_rss.c b/drivers/net/ethernet/huawei/hinic3/hinic3_rss.c
> index 25db74d8c7dd..1c8aea9d8887 100644
> --- a/drivers/net/ethernet/huawei/hinic3/hinic3_rss.c
> +++ b/drivers/net/ethernet/huawei/hinic3/hinic3_rss.c
> @@ -155,7 +155,7 @@ static int hinic3_set_rss_type(struct hinic3_hwdev *hwdev,
> L2NIC_CMD_SET_RSS_CTX_TBL, &msg_params);
>
> if (ctx_tbl.msg_head.status == MGMT_STATUS_CMD_UNSUPPORTED) {
> - return MGMT_STATUS_CMD_UNSUPPORTED;
> + return -EOPNOTSUPP;
Looks like an unrelated change?
> } else if (err || ctx_tbl.msg_head.status) {
> dev_err(hwdev->dev, "mgmt Failed to set rss context offload, err: %d, status: 0x%x\n",
> err, ctx_tbl.msg_head.status);
> @@ -165,6 +165,39 @@ static int hinic3_set_rss_type(struct hinic3_hwdev *hwdev,
> return 0;
> }
>
> +static int hinic3_set_rss_hash_opts(struct net_device *netdev,
> + struct ethtool_rxnfc *cmd)
> +{
> + struct hinic3_nic_dev *nic_dev = netdev_priv(netdev);
> + struct hinic3_rss_type *rss_type;
> + int err;
> +
> + rss_type = &nic_dev->rss_type;
> +
> + if (!test_bit(HINIC3_RSS_ENABLE, &nic_dev->flags)) {
> + cmd->data = 0;
> + netdev_err(netdev, "RSS is disable, not support to set flow-hash\n");
> + return -EOPNOTSUPP;
> + }
> +
> + /* RSS only supports hashing of IP addresses and L4 ports */
> + if (cmd->data & ~(RXH_IP_SRC | RXH_IP_DST |
> + RXH_L4_B_0_1 | RXH_L4_B_2_3))
> + return -EINVAL;
> +
> + /* Both IP addresses must be part of the hash tuple */
> + if (!(cmd->data & RXH_IP_SRC) || !(cmd->data & RXH_IP_DST))
> + return -EINVAL;
> +
> + err = hinic3_get_rss_type(nic_dev->hwdev, rss_type);
> + if (err) {
> + netdev_err(netdev, "Failed to get rss type\n");
> + return err;
> + }
> +
> + err = hinic3_update_rss_hash_opts(netdev, cmd, rss_type);
> + if (err)
> + return err;
> +
> + err = hinic3_set_rss_type(nic_dev->hwdev, *rss_type);
So if we fail here, we have already modified the rss_type in-place. From
this on-wards, the HW state would diverge from in-memory state. How
about use a local copy and only update if no error?
> + if (err) {
> + netdev_err(netdev, "Failed to set rss type\n");
> + return err;
> + }
> +
> + return 0;
> +}
> +
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next v1 2/2] igc: use napi_schedule_irqoff() instead of napi_schedule()
From: Loktionov, Aleksandr @ 2026-04-01 7:53 UTC (permalink / raw)
To: Daiki Harada, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Nguyen, Anthony L, Kitszel, Przemyslaw, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Kohei Enju
In-Reply-To: <20260331103924.36422-3-daiky0325@gmail.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Daiki Harada
> Sent: Tuesday, March 31, 2026 12:39 PM
> To: intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Cc: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric
> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>; Daiki Harada <daiky0325@gmail.com>; Kohei
> Enju <kohei@enjuk.jp>
> Subject: [Intel-wired-lan] [PATCH iwl-next v1 2/2] igc: use
> napi_schedule_irqoff() instead of napi_schedule()
>
> Replace napi_schedule() with napi_schedule_irqoff() in the interrupt
> handler path in igc driver Tested on Intel Corporation Ethernet
> Controller I226-V.
>
> Suggested-by: Kohei Enju <kohei@enjuk.jp>
> Signed-off-by: Daiki Harada <daiky0325@gmail.com>
> ---
> drivers/net/ethernet/intel/igc/igc_main.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/igc/igc_main.c
> b/drivers/net/ethernet/intel/igc/igc_main.c
> index 72bc5128d8b8..712605886104 100644
> --- a/drivers/net/ethernet/intel/igc/igc_main.c
> +++ b/drivers/net/ethernet/intel/igc/igc_main.c
> @@ -5688,7 +5688,7 @@ static irqreturn_t igc_msix_ring(int irq, void
> *data)
> /* Write the ITR value calculated from the previous interrupt.
> */
> igc_write_itr(q_vector);
>
> - napi_schedule(&q_vector->napi);
> + napi_schedule_irqoff(&q_vector->napi);
>
> return IRQ_HANDLED;
> }
> @@ -6059,7 +6059,7 @@ static irqreturn_t igc_intr_msi(int irq, void
> *data)
> if (icr & IGC_ICR_TS)
> igc_tsync_interrupt(adapter);
>
> - napi_schedule(&q_vector->napi);
> + napi_schedule_irqoff(&q_vector->napi);
>
> return IRQ_HANDLED;
> }
> @@ -6105,7 +6105,7 @@ static irqreturn_t igc_intr(int irq, void *data)
> if (icr & IGC_ICR_TS)
> igc_tsync_interrupt(adapter);
>
> - napi_schedule(&q_vector->napi);
> + napi_schedule_irqoff(&q_vector->napi);
>
> return IRQ_HANDLED;
> }
> --
> 2.53.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net] i40e: fix memcmp of pointer in i40e_hw_set_dcb_config()
From: Loktionov, Aleksandr @ 2026-04-01 7:54 UTC (permalink / raw)
To: Aaron Esau, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Nguyen, Anthony L, Kitszel, Przemyslaw,
Kubalewski, Arkadiusz, stable@vger.kernel.org
In-Reply-To: <20260329162151.2043655-1-aaron1esau@gmail.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Aaron Esau
> Sent: Sunday, March 29, 2026 6:22 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Nguyen, Anthony L
> <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Kubalewski, Arkadiusz
> <arkadiusz.kubalewski@intel.com>; stable@vger.kernel.org; Aaron Esau
> <aaron1esau@gmail.com>
> Subject: [Intel-wired-lan] [PATCH net] i40e: fix memcmp of pointer in
> i40e_hw_set_dcb_config()
>
> In i40e_hw_set_dcb_config(), both new_cfg and old_cfg are pointers to
> struct i40e_dcbx_config, so sizeof(new_cfg) evaluates to the size of a
> pointer (8 bytes on 64-bit) rather than the size of the struct.
> Likewise, &new_cfg and &old_cfg are the addresses of the pointer
> variables on the stack, not the addresses of the actual config
> structs.
>
> As a result, the memcmp never compares the actual configuration data,
> meaning the "no change needed" early return never fires. Every call to
> this function performs a full DCB reconfiguration (quiescing all VSIs,
> reprogramming via "Set LLDP MIB" AQC, and reconfiguring VEB/VSIs) even
> when the configuration has not changed.
>
> Fix this by comparing the structs themselves rather than the pointers.
>
> Fixes: 4b208eaa8078 ("i40e: Add init and default config of software
> based DCB")
> Cc: stable@vger.kernel.org
> Signed-off-by: Aaron Esau <aaron1esau@gmail.com>
> ---
>
> Found using Coccinelle/spatch with a semantic patch that matches
> sizeof(ptr) and &ptr used together where ptr is a pointer type.
>
> drivers/net/ethernet/intel/i40e/i40e_main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index XXXXXXX..XXXXXXX 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -6904,7 +6904,7 @@ static int i40e_hw_set_dcb_config(struct i40e_pf
> *pf,
> int ret;
>
> /* Check if need reconfiguration */
> - if (!memcmp(&new_cfg, &old_cfg, sizeof(new_cfg))) {
> + if (!memcmp(new_cfg, old_cfg, sizeof(*new_cfg))) {
> dev_dbg(&pf->pdev->dev, "No Change in DCB Config
> required.\n");
> return 0;
> }
> --
> 2.49.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* [PATCH net v2] ipvs: fix NULL deref in ip_vs_add_service error path
From: Weiming Shi @ 2026-04-01 7:58 UTC (permalink / raw)
To: Simon Horman, Julian Anastasov, Pablo Neira Ayuso,
Florian Westphal, David S . Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni
Cc: Phil Sutter, netdev, lvs-devel, netfilter-devel, coreteam,
Xiang Mei, Weiming Shi
When ip_vs_bind_scheduler() succeeds in ip_vs_add_service(), the local
variable sched is set to NULL. If ip_vs_start_estimator() subsequently
fails, the out_err cleanup calls ip_vs_unbind_scheduler(svc, sched)
with sched == NULL. ip_vs_unbind_scheduler() passes the cur_sched NULL
check (because svc->scheduler was set by the successful bind) but then
dereferences the NULL sched parameter at sched->done_service, causing a
kernel panic at offset 0x30 from NULL.
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000006: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000030-0x0000000000000037]
RIP: 0010:ip_vs_unbind_scheduler (net/netfilter/ipvs/ip_vs_sched.c:69)
Call Trace:
<TASK>
ip_vs_add_service.isra.0 (net/netfilter/ipvs/ip_vs_ctl.c:1500)
do_ip_vs_set_ctl (net/netfilter/ipvs/ip_vs_ctl.c:2809)
nf_setsockopt (net/netfilter/nf_sockopt.c:102)
ip_setsockopt (net/ipv4/ip_sockglue.c:1427)
raw_setsockopt (net/ipv4/raw.c:850)
do_sock_setsockopt (net/socket.c:2322)
__sys_setsockopt (net/socket.c:2339)
__x64_sys_setsockopt (net/socket.c:2350)
do_syscall_64 (arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
</TASK>
Fix by simply not clearing the local sched variable after a successful
bind. ip_vs_unbind_scheduler() already detects whether a scheduler is
installed via svc->scheduler, and keeping sched non-NULL ensures the
error path passes the correct pointer to both ip_vs_unbind_scheduler()
and ip_vs_scheduler_put().
Fixes: 05f00505a89a ("ipvs: fix crash if scheduler is changed")
Reported-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
---
v2: Remove "sched = NULL" instead of recovering it in out_err (Julian)
net/netfilter/ipvs/ip_vs_ctl.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
index 35642de2a0fee..2aaf50f52c8e8 100644
--- a/net/netfilter/ipvs/ip_vs_ctl.c
+++ b/net/netfilter/ipvs/ip_vs_ctl.c
@@ -1452,7 +1452,6 @@ ip_vs_add_service(struct netns_ipvs *ipvs, struct ip_vs_service_user_kern *u,
ret = ip_vs_bind_scheduler(svc, sched);
if (ret)
goto out_err;
- sched = NULL;
}
ret = ip_vs_start_estimator(ipvs, &svc->stats);
--
2.43.0
^ permalink raw reply related
* Re: [PATCH 0/6] Deprecate Legacy IP
From: Fernando Fernandez Mancera @ 2026-04-01 8:07 UTC (permalink / raw)
To: David Woodhouse, Saeed Mahameed, Leon Romanovsky, Tariq Toukan,
Mark Bloch, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Simon Horman, Nikolay Aleksandrov,
Ido Schimmel, Martin KaFai Lau, Daniel Borkmann, John Fastabend,
Stanislav Fomichev, Alexei Starovoitov, Andrii Nakryiko,
Eduard Zingerman, Song Liu, Yonghong Song, KP Singh, Hao Luo,
Jiri Olsa, Kuniyuki Iwashima, Willem de Bruijn, David Ahern,
Neal Cardwell, Johannes Berg, Pablo Neira Ayuso, Florian Westphal,
Phil Sutter, Guillaume Nault, David Woodhouse, Kees Cook,
Alexei Lazar, Gal Pressman, Paul Moore, netdev, linux-rdma,
linux-kernel, oss-drivers, bridge, bpf, linux-wireless,
netfilter-devel, coreteam, torvalds, jon.maddog.hall
In-Reply-To: <20260401074509.1897527-1-dwmw2@infradead.org>
On 4/1/26 9:44 AM, David Woodhouse wrote:
> RFC1883, the IPv6 standard, was published in the final decade of the 1900s.
> That's closer in time to the Apollo 11 moon landing than it was to today.
>
> Even our esteemed Maddog has worked with computers for longer in the IPv6
> era, than he ever did before it.
>
> Yet Linux still can't even be *built* with only IPv6 support and without
> support for Legacy IP. This long overdue patch series fixes that, and
> immediately marks Legacy IP for deprecation.
>
> It also cleans up a few tautological "INET && IPV6" and "INET || IPV6"
> checks, since IPV6 (and now LEGACY_IP) cannot be selected without the
> overall CONFIG_INET option.
>
> For now, we only add a warning when a process *listens* on a Legacy IP
> socket (since you can listen on IPv6 and still accept connections which
> have come through a timewarp from the 20th century. Adding warnings for
> making outbound connections or *accepting* on Legacy IP can come later.
>
> 'I would be happy if "Legacy IP" ceased to be the "industry standard"
> and IPv6 be the default, even if I had to beat IPv6 into the head of
> every single network administrator's head with a shovel.' said Jon
> 'maddog' Hall, ancient supporter of Free and Open Source Software.
>
Dammit, you've beaten me to it! This was my next step for 7.2.
Fully-endorsed-by: Fernando Fernandez Mancera <fmancera@suse.de>
^ permalink raw reply
* Re: [PATCH v8 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: Pawan Gupta @ 2026-04-01 8:12 UTC (permalink / raw)
To: David Laight
Cc: Borislav Petkov, x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin,
Josh Poimboeuf, David Kaplan, Sean Christopherson, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
Andy Lutomirski, Thomas Gleixner, Ingo Molnar, David Ahern,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, Stanislav Fomichev, Hao Luo, Paolo Bonzini,
Jonathan Corbet, linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf,
netdev, linux-doc
In-Reply-To: <20260328100837.7e6dc7fe@pumpkin>
On Sat, Mar 28, 2026 at 10:08:37AM +0000, David Laight wrote:
> On Fri, 27 Mar 2026 17:42:56 -0700
> Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote:
>
> > On Thu, Mar 26, 2026 at 01:29:31PM -0700, Pawan Gupta wrote:
> > > On Thu, Mar 26, 2026 at 10:45:57AM +0000, David Laight wrote:
> > > > On Thu, 26 Mar 2026 11:01:20 +0100
> > > > Borislav Petkov <bp@alien8.de> wrote:
> > > >
> > > > > On Thu, Mar 26, 2026 at 01:39:34AM -0700, Pawan Gupta wrote:
> > > > > > I believe the equivalent for cpu_feature_enabled() in asm is the
> > > > > > ALTERNATIVE. Please let me know if I am missing something.
> > > > >
> > > > > Yes, you are.
> > > > >
> > > > > The point is that you don't want to stick those alternative calls inside some
> > > > > magic bhb_loop function but hand them in from the outside, as function
> > > > > arguments.
> > > > >
> > > > > Basically what I did.
> > > > >
> > > > > Then you were worried about this being C code and it had to be noinstr... So
> > > > > that outer function can be rewritten in asm, I think, and still keep it well
> > > > > separate.
> > > > >
> > > > > I'll try to rewrite it once I get a free minute, and see how it looks.
> > > > >
> > > >
> > > > I think someone tried getting C code to write the values to global data
> > > > and getting the asm to read them.
> > > > That got discounted because it spilt things between two largely unrelated files.
> > >
> > >
> > > The implementation with global variables wasn't that bad, let me revive it.
> > >
> > > This part which ties sequence to BHI mitigation, which is not ideal,
> > > (because VMSCAPE also uses it) it does seems a cleaner option.
> > >
> > > --- a/arch/x86/kernel/cpu/bugs.c
> > > +++ b/arch/x86/kernel/cpu/bugs.c
> > > @@ -2095,6 +2095,11 @@ static void __init bhi_select_mitigation(void)
> > >
> > > static void __init bhi_update_mitigation(void)
> > > {
> > > + if (!cpu_feature_enabled(X86_FEATURE_BHI_CTRL)) {
> > > + bhi_seq_outer_loop = 5;
> > > + bhi_seq_inner_loop = 5;
> > > + }
> > > +
> > >
> > > I believe this can be moved to somewhere common to all mitigations.
> > >
> > > > I think the BPF code would need significant refactoring to call a C function.
> > >
> > > Ya, true. Will use globals and keep clear_bhb_loop() in asm.
> >
> > While testing this approach, I noticed that syscalls were suffering an 8%
> > regression on ICX for Native BHI mitigation:
> >
> > $ perf bench syscall basic -l 100000000
> >
> > Bisection pointed to the change for using 8-bit registers (al/ah replacing
> > eax/ecx) as the main contributor to the regression. (Global variables added
> > a bit, but within noise).
> >
> > Further digging revealed a strange behavior, using %ah for the inner loop
> > was causing the regression, interchanging %al and %ah in the loops
> > (for movb and sub) eliminated the regression.
> >
> > <clear_bhb_loop_nofence>:
> >
> > movb bhb_seq_outer_loop(%rip), %al
> >
> > call 1f
> > jmp 5f
> > 1: call 2f
> > .Lret1: RET
> > 2: movb bhb_seq_inner_loop(%rip), %ah
> > 3: jmp 4f
> > nop
> > 4: sub $1, %ah <---- No regression with %al here
> > jnz 3b
> > sub $1, %al
> > jnz 1b
> >
> > My guess is, "sub $1, %al" is faster than "sub $1, %ah". Using %al in the
> > inner loop, which is executed more number of times is likely making the
> > difference. A perf profile is needed to confirm this.
>
> I bet it is also CPU dependant - it is quite likely that there isn't
> any special hardware to support partial writes of %ah so it ends up taking
> a slow path (possibly even a microcoded one to get an 8% regression).
Strangely, %ah in the inner loop incurs less uops and has fewer branch
misses, yet takes more cycles. Below is the perf data for the sequence on a
Rocket Lake (similar observation on ICX and EMR):
Event %al inner %ah inner Delta
---------------------- ------------- ------------- ----------
cycles 776,775,020 972,322,384 +25.2%
instructions/cycle 1.23 0.98 -20.3%
branch-misses 4,792,502 560,449 -88.3%
uops_issued.any 768,019,010 696,888,357 -9.3%
time elapsed 0.1627s 0.2048s +25.9%
Time elapsed directly correlates with the increase in cycles.
> As well as swapping %al <-> %ah try changing the outer loop decrement to
> sub $0x100, %ax
> since %al is zero that will set the z flag the same.
Unfortunately, using "sub $0x100, %ax"(with %al as inner loop) isn't better
than just using "sub $1, %ah" in the outer loop:
Event %al inner + sub %ax Delta
---------------------- ------------- ------------- ----------
cycles 776,775,020 813,372,036 +4.7%
instructions/cycle 1.23 1.17 -4.5%
branch-misses 4,792,502 7,610,323 +58.8%
uops_issued.any 768,019,010 827,465,137 +7.7%
time elapsed 0.1627s 0.1707s +4.9%
> I've just hacked a test into some test code I've got.
> I'm not seeing an unexpected costs on either zen-5 or haswell.
> So it may be more subtle.
This is puzzling, but atleast it is evident that using %al for the inner
loop seems to be the best option. In summary:
Variant Cycles Uops Issued Branch Misses
------- ---------- ----------- -------------
%al 776M 768M 4.8M (fastest)
%ah 972M (+25%) 697M (-9%) 560K (-88%) (fewer uops + misses, yet slowest)
sub %ax 813M (+5%) 827M (+8%) 7.6M (+59%) (most uops + misses)
^ permalink raw reply
* Re: [PATCH v8 04/10] x86/vmscape: Rename x86_ibpb_exit_to_user to x86_predictor_flush_exit_to_user
From: Pawan Gupta @ 2026-04-01 8:13 UTC (permalink / raw)
To: Sean Christopherson
Cc: x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin, Josh Poimboeuf,
David Kaplan, Borislav Petkov, Dave Hansen, Peter Zijlstra,
Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko, KP Singh,
Jiri Olsa, David S. Miller, David Laight, Andy Lutomirski,
Thomas Gleixner, Ingo Molnar, David Ahern, Martin KaFai Lau,
Eduard Zingerman, Song Liu, Yonghong Song, John Fastabend,
Stanislav Fomichev, Hao Luo, Paolo Bonzini, Jonathan Corbet,
linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf, netdev,
linux-doc
In-Reply-To: <acwJVUeW9KoLft4d@google.com>
On Tue, Mar 31, 2026 at 10:50:13AM -0700, Sean Christopherson wrote:
> On Tue, Mar 24, 2026, Pawan Gupta wrote:
> > With the upcoming changes x86_ibpb_exit_to_user will also be used when BHB
> > clearing sequence is used. Rename it cover both the cases.
> >
> > No functional change.
> >
> > Suggested-by: Sean Christopherson <seanjc@google.com>
> > Signed-off-by: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> > ---
>
> Acked-by: Sean Christopherson <seanjc@google.com>
Thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 2/9] dt-bindings: net: lan9645x: add LAN9645X switch bindings
From: Jens Emil Schulz Ostergaard @ 2026-04-01 8:16 UTC (permalink / raw)
To: Jakub Kicinski
Cc: UNGLinuxDriver, andrew, olteanv, davem, edumazet, pabeni, horms,
robh, krzk+dt, conor+dt, woojung.huh, linux, Steen.Hegelund,
daniel.machon, linux-kernel, netdev, devicetree
In-Reply-To: <20260329195625.2789069-1-kuba@kernel.org>
On Sun, 2026-03-29 at 12:56 -0700, Jakub Kicinski wrote:
> EXTERNAL EMAIL: Do not click links or open attachments unless you know the content is safe
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> ---
> dt-bindings: net: lan9645x: add LAN9645X switch bindings
>
> Add bindings for LAN9645X switch. We use a fallback compatible for the
> smallest SKU microchip,lan96455s-switch.
>
> > diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
> > new file mode 100644
> > index 000000000000..0282e25c05d4
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/net/dsa/microchip,lan96455s-switch.yaml
>
> [ ... ]
>
> > +patternProperties:
> > + "^(ethernet-)?ports$":
> > + type: object
> > + additionalProperties: true
> > + patternProperties:
> > + "^(ethernet-)?port@[0-8]$":
>
> Does having additionalProperties set to true bypass the port number
> restriction?
>
> Since dsa.yaml allows port@[0-9a-f]+, it seems port@9 would silently pass
> validation as an additional property. Should this be unevaluatedProperties
> set to false instead?
>
Yes it is true the port regex has no effect, but I do not think
unevaluatedProperties: false
is what I want here. That rejects other properties from the parent. I can
remove the explicit additionalProperties: true. This is similar to
Documentation/devicetree/bindings/net/dsa/lantiq,gswip.yaml
and the port number restriction still serves as documentation, even if it is
not applied during validation.
> > + type: object
> > + description: Ethernet switch ports
> > +
> > + $ref: dsa-port.yaml#
> > +
> > + properties:
> > + rx-internal-delay-ps:
> > + const: 2000
> > +
> > + tx-internal-delay-ps:
> > + const: 2000
>
> Does enforcing a 2000ps delay conflict with standard rgmii bindings?
>
> As documented in net/ethernet-controller.yaml, a full 2ns delay is
> typically modeled using phy-mode set to rgmii-id rather than hardcoding the
> delay properties with a base rgmii mode.
>
No this was explicitly requested on v1 to enable adding a delay with mac2mac links.
I enforce 2000ps because that is the only supported value.
> [ ... ]
>
> > +required:
> > + - compatible
> > + - reg
> > +
> > +unevaluatedProperties: false
>
> How are the five integrated 10/100/1000Base-T phys mentioned in the
> description modeled?
>
> Since unevaluatedProperties is false at the top level and there is no
> definition or reference for an mdio node, wouldn't adding an mdio subnode
> to configure these phys fail schema validation?
>
> Should there be a reference to /schemas/net/mdio.yaml#?
No, the MDIO busses will be part of a parent MFD device node, not the switch node.
^ permalink raw reply
* [PATCH 1/2 net v2] ipv4: nexthop: avoid duplicate NHA_HW_STATS_ENABLE on nexthop group dump
From: Fernando Fernandez Mancera @ 2026-04-01 8:17 UTC (permalink / raw)
To: netdev
Cc: idosch, petrm, horms, pabeni, kuba, edumazet, davem, dsahern,
kees, Fernando Fernandez Mancera
Currently NHA_HW_STATS_ENABLE is included twice everytime a dump of
nexthop group is performed with NHA_OP_FLAG_DUMP_STATS. As all the stats
querying were moved to nla_put_nh_group_stats(), leave only that
instance of the attribute querying.
Fixes: 5072ae00aea4 ("net: nexthop: Expose nexthop group HW stats to user space")
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
---
v2: patch added on this revision
---
net/ipv4/nexthop.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
index c942f1282236..a0c694583299 100644
--- a/net/ipv4/nexthop.c
+++ b/net/ipv4/nexthop.c
@@ -902,8 +902,7 @@ static int nla_put_nh_group(struct sk_buff *skb, struct nexthop *nh,
goto nla_put_failure;
if (op_flags & NHA_OP_FLAG_DUMP_STATS &&
- (nla_put_u32(skb, NHA_HW_STATS_ENABLE, nhg->hw_stats) ||
- nla_put_nh_group_stats(skb, nh, op_flags)))
+ nla_put_nh_group_stats(skb, nh, op_flags))
goto nla_put_failure;
return 0;
--
2.53.0
^ permalink raw reply related
* [PATCH 2/2 net v2] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
From: Fernando Fernandez Mancera @ 2026-04-01 8:17 UTC (permalink / raw)
To: netdev
Cc: idosch, petrm, horms, pabeni, kuba, edumazet, davem, dsahern,
kees, Fernando Fernandez Mancera, Yiming Qian
In-Reply-To: <20260401081741.4273-1-fmancera@suse.de>
When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently
allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for
single nexthops and small Equal-Cost Multi-Path groups, this fixed
allocation fails for large nexthop groups like 512 nexthops.
This results in the following warning splat:
WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608
[...]
RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395)
[...]
Call Trace:
<TASK>
rtnetlink_rcv_msg (net/core/rtnetlink.c:6989)
netlink_rcv_skb (net/netlink/af_netlink.c:2550)
netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)
netlink_sendmsg (net/netlink/af_netlink.c:1894)
____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585)
___sys_sendmsg (net/socket.c:2641)
__sys_sendmsg (net/socket.c:2671)
do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
</TASK>
Fix this by allocating the size dynamically using nh_nlmsg_size() and
using nlmsg_new(), this is consistent with nexthop_notify() behavior. In
addition, adjust nh_nlmsg_size_grp() so it calculates the size needed
based on flags passed.
This cannot be reproduced via iproute2 as the group size is currently
limited and the command fails as follows:
addattr_l ERROR: message exceeded bound of 1048
Fixes: 430a049190de ("nexthop: Add support for nexthop groups")
Reported-by: Yiming Qian <yimingqian591@gmail.com>
Closes: https://lore.kernel.org/netdev/CAL_bE8Li2h4KO+AQFXW4S6Yb_u5X4oSKnkywW+LPFjuErhqELA@mail.gmail.com/
Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
---
v2: adjust nh_nlmsg_size_grp() to handle size for stats and add symbols
to the trace in commit message
---
net/ipv4/nexthop.c | 35 +++++++++++++++++++++++++----------
1 file changed, 25 insertions(+), 10 deletions(-)
diff --git a/net/ipv4/nexthop.c b/net/ipv4/nexthop.c
index a0c694583299..9abbf3989f23 100644
--- a/net/ipv4/nexthop.c
+++ b/net/ipv4/nexthop.c
@@ -1003,7 +1003,7 @@ static size_t nh_nlmsg_size_grp_res(struct nh_group *nhg)
nla_total_size_64bit(8);/* NHA_RES_GROUP_UNBALANCED_TIME */
}
-static size_t nh_nlmsg_size_grp(struct nexthop *nh)
+static size_t nh_nlmsg_size_grp(struct nexthop *nh, u32 op_flags)
{
struct nh_group *nhg = rtnl_dereference(nh->nh_grp);
size_t sz = sizeof(struct nexthop_grp) * nhg->num_nh;
@@ -1013,6 +1013,21 @@ static size_t nh_nlmsg_size_grp(struct nexthop *nh)
if (nhg->resilient)
tot += nh_nlmsg_size_grp_res(nhg);
+ if (op_flags & NHA_OP_FLAG_DUMP_STATS) {
+ tot += nla_total_size(0) + /* NHA_GROUP_STATS */
+ nla_total_size(4); /* NHA_HW_STATS_ENABLE */
+ tot += nhg->num_nh *
+ (nla_total_size(0) + /* NHA_GROUP_STATS_ENTRY */
+ nla_total_size(4) + /* NHA_GROUP_STATS_ENTRY_ID */
+ nla_total_size_64bit(8)); /* NHA_GROUP_STATS_ENTRY_PACKETS */
+
+ if (op_flags & NHA_OP_FLAG_DUMP_HW_STATS) {
+ tot += nhg->num_nh *
+ nla_total_size_64bit(8); /* NHA_GROUP_STATS_ENTRY_PACKETS_HW */
+ tot += nla_total_size(4); /* NHA_HW_STATS_USED */
+ }
+ }
+
return tot;
}
@@ -1047,14 +1062,14 @@ static size_t nh_nlmsg_size_single(struct nexthop *nh)
return sz;
}
-static size_t nh_nlmsg_size(struct nexthop *nh)
+static size_t nh_nlmsg_size(struct nexthop *nh, u32 op_flags)
{
size_t sz = NLMSG_ALIGN(sizeof(struct nhmsg));
sz += nla_total_size(4); /* NHA_ID */
if (nh->is_group)
- sz += nh_nlmsg_size_grp(nh) +
+ sz += nh_nlmsg_size_grp(nh, op_flags) +
nla_total_size(4) + /* NHA_OP_FLAGS */
0;
else
@@ -1070,7 +1085,7 @@ static void nexthop_notify(int event, struct nexthop *nh, struct nl_info *info)
struct sk_buff *skb;
int err = -ENOBUFS;
- skb = nlmsg_new(nh_nlmsg_size(nh), gfp_any());
+ skb = nlmsg_new(nh_nlmsg_size(nh, 0), gfp_any());
if (!skb)
goto errout;
@@ -3376,15 +3391,15 @@ static int rtm_get_nexthop(struct sk_buff *in_skb, struct nlmsghdr *nlh,
if (err)
return err;
- err = -ENOBUFS;
- skb = alloc_skb(NLMSG_GOODSIZE, GFP_KERNEL);
- if (!skb)
- goto out;
-
err = -ENOENT;
nh = nexthop_find_by_id(net, id);
if (!nh)
- goto errout_free;
+ goto out;
+
+ err = -ENOBUFS;
+ skb = nlmsg_new(nh_nlmsg_size(nh, op_flags), GFP_KERNEL);
+ if (!skb)
+ goto out;
err = nh_fill_node(skb, nh, RTM_NEWNEXTHOP, NETLINK_CB(in_skb).portid,
nlh->nlmsg_seq, 0, op_flags);
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net,v5] virtio_net: clamp rss_max_key_size to NETDEV_RSS_KEY_LEN
From: Michael S. Tsirkin @ 2026-04-01 8:21 UTC (permalink / raw)
To: Srujana Challa
Cc: netdev, virtualization, pabeni, jasowang, xuanzhuo, eperezma,
davem, edumazet, kuba, ndabilpuram, kshankar, stable
In-Reply-To: <20260326142344.1171317-1-schalla@marvell.com>
On Thu, Mar 26, 2026 at 07:53:44PM +0530, Srujana Challa wrote:
> rss_max_key_size in the virtio spec is the maximum key size supported by
> the device, not a mandatory size the driver must use. Also the value 40
> is a spec minimum, not a spec maximum.
>
> The current code rejects RSS and can fail probe when the device reports a
> larger rss_max_key_size than the driver buffer limit. Instead, clamp the
> effective key length to min(device rss_max_key_size, NETDEV_RSS_KEY_LEN)
> and keep RSS enabled.
>
> This keeps probe working on devices that advertise larger maximum key sizes
> while respecting the netdev RSS key buffer size limit.
>
> Fixes: 3f7d9c1964fc ("virtio_net: Add hash_key_length check")
> Cc: stable@vger.kernel.org
> Signed-off-by: Srujana Challa <schalla@marvell.com>
Acked-by: Michael S. Tsirkin <mst@redhat.com>
> ---
> v3:
> - Moved RSS key validation checks to virtnet_validate.
> - Add fixes: tag and CC -stable
> v4:
> - Use NETDEV_RSS_KEY_LEN instead of type_max for the maximum rss key size.
> v5:
> - Interpret rss_max_key_size as a maximum and clamp it to NETDEV_RSS_KEY_LEN.
> - Do not disable RSS/HASH_REPORT when device rss_max_key_size exceeds NETDEV_RSS_KEY_LEN.
> - Drop the separate patch that replaced the runtime check with BUILD_BUG_ON.
>
> drivers/net/virtio_net.c | 20 +++++++++-----------
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> index 022f60728721..b241c8dbb4e1 100644
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -373,8 +373,6 @@ struct receive_queue {
> struct xdp_buff **xsk_buffs;
> };
>
> -#define VIRTIO_NET_RSS_MAX_KEY_SIZE 40
> -
> /* Control VQ buffers: protected by the rtnl lock */
> struct control_buf {
> struct virtio_net_ctrl_hdr hdr;
> @@ -478,7 +476,7 @@ struct virtnet_info {
>
> /* Must be last as it ends in a flexible-array member. */
> TRAILING_OVERLAP(struct virtio_net_rss_config_trailer, rss_trailer, hash_key_data,
> - u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];
> + u8 rss_hash_key_data[NETDEV_RSS_KEY_LEN];
> );
> };
> static_assert(offsetof(struct virtnet_info, rss_trailer.hash_key_data) ==
> @@ -6717,6 +6715,7 @@ static int virtnet_probe(struct virtio_device *vdev)
> struct virtnet_info *vi;
> u16 max_queue_pairs;
> int mtu = 0;
> + u16 key_sz;
>
> /* Find if host supports multiqueue/rss virtio_net device */
> max_queue_pairs = 1;
> @@ -6851,14 +6850,13 @@ static int virtnet_probe(struct virtio_device *vdev)
> }
>
> if (vi->has_rss || vi->has_rss_hash_report) {
> - vi->rss_key_size =
> - virtio_cread8(vdev, offsetof(struct virtio_net_config, rss_max_key_size));
> - if (vi->rss_key_size > VIRTIO_NET_RSS_MAX_KEY_SIZE) {
> - dev_err(&vdev->dev, "rss_max_key_size=%u exceeds the limit %u.\n",
> - vi->rss_key_size, VIRTIO_NET_RSS_MAX_KEY_SIZE);
> - err = -EINVAL;
> - goto free;
> - }
> + key_sz = virtio_cread8(vdev, offsetof(struct virtio_net_config, rss_max_key_size));
> +
> + vi->rss_key_size = min_t(u16, key_sz, NETDEV_RSS_KEY_LEN);
> + if (key_sz > vi->rss_key_size)
> + dev_warn(&vdev->dev,
> + "rss_max_key_size=%u exceeds driver limit %u, clamping\n",
> + key_sz, vi->rss_key_size);
>
> vi->rss_hash_types_supported =
> virtio_cread32(vdev, offsetof(struct virtio_net_config, supported_hash_types));
> --
> 2.25.1
^ permalink raw reply
* Re: [EXTERNAL] Re: [PATCH net,v5] virtio_net: clamp rss_max_key_size to NETDEV_RSS_KEY_LEN
From: Michael S. Tsirkin @ 2026-04-01 8:21 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Paolo Abeni, Srujana Challa, netdev@vger.kernel.org,
virtualization@lists.linux.dev, jasowang@redhat.com,
xuanzhuo@linux.alibaba.com, eperezma@redhat.com,
davem@davemloft.net, edumazet@google.com, Nithin Kumar Dabilpuram,
Shiva Shankar Kommula, stable@vger.kernel.org
In-Reply-To: <20260331180522.64ef9886@kernel.org>
On Tue, Mar 31, 2026 at 06:05:22PM -0700, Jakub Kicinski wrote:
> On Tue, 31 Mar 2026 10:48:41 -0400 Michael S. Tsirkin wrote:
> > > > Thank you for the feedback. In net-next, NETDEV_RSS_KEY_LEN is 256. This fix is
> > > > also intended for stable kernels, where NETDEV_RSS_KEY_LEN is 52, and
> > > > I added the message to make clamping visible in that case.
> > > > I will remove the check and send the next version.
> > >
> > > I'm sorry, I haven't looked at the historical context when I wrote my
> > > previous reply.
> > >
> > > IMHO the additional check does not make sense in the current net tree.
> > > On the flip side stable trees will need it. I suggest:
> > >
> > > - dropping the check for the 'net' patch
> > > - also dropping CC: stable tag
> > > - explicitly sending to stable the fix variant including the size check.
> > >
> > > @Michael: WDYT?
> >
> > I was the one who suggested it, the extra check is harmless, I'm
> > inclined to always have it. Less work than maintaining two patches.
>
> Give us an RB tag please and lets close this one? :)
Oh I thought I did. Thanks.
^ permalink raw reply
* Re: [PATCH][net-next] net/mlx5: Move command entry freeing outside of spinlock
From: Tariq Toukan @ 2026-04-01 8:21 UTC (permalink / raw)
To: lirongqing, Saeed Mahameed, Leon Romanovsky, Tariq Toukan,
Mark Bloch, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-rdma, linux-kernel
In-Reply-To: <20260331122604.1933-1-lirongqing@baidu.com>
On 31/03/2026 15:26, lirongqing wrote:
> From: Li RongQing <lirongqing@baidu.com>
>
> Move the kfree() call outside the critical section to reduce lock
> holding time. This aligns with the general principle of minimizing
> work under locks.
>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
> ---
> drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 9 +++++----
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
> index 6c99c7f..c89417c 100644
> --- a/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
> +++ b/drivers/net/ethernet/mellanox/mlx5/core/cmd.c
> @@ -196,17 +196,18 @@ static void cmd_ent_put(struct mlx5_cmd_work_ent *ent)
> unsigned long flags;
>
> spin_lock_irqsave(&cmd->alloc_lock, flags);
> - if (!refcount_dec_and_test(&ent->refcnt))
> - goto out;
> + if (!refcount_dec_and_test(&ent->refcnt)) {
> + spin_unlock_irqrestore(&cmd->alloc_lock, flags);
> + return;
> + }
>
> if (ent->idx >= 0) {
> cmd_free_index(cmd, ent->idx);
> up(ent->page_queue ? &cmd->vars.pages_sem : &cmd->vars.sem);
> }
> + spin_unlock_irqrestore(&cmd->alloc_lock, flags);
>
> cmd_free_ent(ent);
> -out:
> - spin_unlock_irqrestore(&cmd->alloc_lock, flags);
> }
>
> static struct mlx5_cmd_layout *get_inst(struct mlx5_cmd *cmd, int idx)
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
Thanks.
^ permalink raw reply
* Re: [PATCH 0/6] Deprecate Legacy IP
From: David Woodhouse @ 2026-04-01 8:25 UTC (permalink / raw)
To: Fernando Fernandez Mancera, Saeed Mahameed, Leon Romanovsky,
Tariq Toukan, Mark Bloch, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
Nikolay Aleksandrov, Ido Schimmel, Martin KaFai Lau,
Daniel Borkmann, John Fastabend, Stanislav Fomichev,
Alexei Starovoitov, Andrii Nakryiko, Eduard Zingerman, Song Liu,
Yonghong Song, KP Singh, Hao Luo, Jiri Olsa, Kuniyuki Iwashima,
Willem de Bruijn, David Ahern, Neal Cardwell, Johannes Berg,
Pablo Neira Ayuso, Florian Westphal, Phil Sutter, Guillaume Nault,
Kees Cook, Alexei Lazar, Gal Pressman, Paul Moore, netdev,
linux-rdma, linux-kernel, oss-drivers, bridge, bpf,
linux-wireless, netfilter-devel, coreteam, torvalds,
jon.maddog.hall
In-Reply-To: <42caa438-3854-449c-b0ee-4f40772e5c1b@suse.de>
[-- Attachment #1: Type: text/plain, Size: 745 bytes --]
On Wed, 2026-04-01 at 10:07 +0200, Fernando Fernandez Mancera wrote:
>
>
> Dammit, you've beaten me to it! This was my next step for 7.2.
>
> Fully-endorsed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Yeah. The date notwithstanding, I do actually think we should do most
of this for real.
Maybe we don't get away with the actual deprecation and the warnings on
use *just* yet, and *maybe* we won't even get away with calling the
config option CONFIG_LEGACY_IP, although I would genuinely like to see
us moving consistently towards saying "Legacy IP" instead of "IPv4"
everywhere.
But we *should* clean up the separation of CONFIG_INET and
CONFIG_IPV[64] and make it possible to build with either protocol
alone.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH net-next] Octeontx2-af: add WQ_PERCPU to alloc_workqueue users
From: Subbaraya Sundeep @ 2026-04-01 8:32 UTC (permalink / raw)
To: Marco Crivellari
Cc: linux-kernel, netdev, Tejun Heo, Lai Jiangshan,
Frederic Weisbecker, Sebastian Andrzej Siewior, Michal Hocko,
Sunil Goutham, Linu Cherian, Geetha sowjanya, Jerin Jacob,
hariprasad, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni
In-Reply-To: <20260330095405.116990-1-marco.crivellari@suse.com>
On 2026-03-30 at 15:24:05, Marco Crivellari (marco.crivellari@suse.com) wrote:
> This continues the effort to refactor workqueue APIs, which began with
> the introduction of new workqueues and a new alloc_workqueue flag in:
>
> commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
> commit 930c2ea566af ("workqueue: Add new WQ_PERCPU flag")
>
> The refactoring is going to alter the default behavior of
> alloc_workqueue() to be unbound by default.
>
> With the introduction of the WQ_PERCPU flag (equivalent to !WQ_UNBOUND),
> any alloc_workqueue() caller that doesn’t explicitly specify WQ_UNBOUND
> must now use WQ_PERCPU. For more details see the Link tag below.
>
> In order to keep alloc_workqueue() behavior identical, explicitly request
> WQ_PERCPU.
>
> Link: https://lore.kernel.org/all/20250221112003.1dSuoGyc@linutronix.de/
> Suggested-by: Tejun Heo <tj@kernel.org>
> Signed-off-by: Marco Crivellari <marco.crivellari@suse.com>
Reviewed-by: Subbaraya Sundeep <sbhatta@marvell.com>
Thanks,
Sundeep
> ---
> drivers/net/ethernet/marvell/octeontx2/af/rvu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
> index 5b1129558e8b..1a1a863199ee 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu.c
> @@ -2576,7 +2576,7 @@ static int rvu_mbox_init(struct rvu *rvu, struct mbox_wq_info *mw,
> }
>
> mw->mbox_wq = alloc_workqueue("%s",
> - WQ_HIGHPRI | WQ_MEM_RECLAIM,
> + WQ_HIGHPRI | WQ_MEM_RECLAIM | WQ_PERCPU,
> num, name);
> if (!mw->mbox_wq) {
> err = -ENOMEM;
> --
> 2.53.0
>
^ permalink raw reply
* Re: [PATCH 4/6] net: Make IPv4-only Kconfig options depend on LEGACY_IP
From: bot+bpf-ci @ 2026-04-01 8:36 UTC (permalink / raw)
To: dwmw2, saeedm, leon, tariqt, mbloch, andrew+netdev, davem,
edumazet, kuba, pabeni, horms, razor, idosch, martin.lau, daniel,
john.fastabend, sdf, ast, andrii, eddyz87, song, yonghong.song,
kpsingh, haoluo, jolsa, kuniyu, willemb, dsahern, ncardwell,
johannes, pablo, fw, phil, gnault, dwmw, kees, alazar, gal, paul,
netdev, linux-rdma, linux-kernel, oss-drivers, bridge, bpf,
linux-wireless, netfilter-devel, coreteam, torvalds,
jon.maddog.hall
Cc: ast, andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260401074509.1897527-5-dwmw2@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 2543 bytes --]
> diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
> index aef2c5349e62..03b5ba75c3cf 100644
> --- a/net/ipv4/Kconfig
> +++ b/net/ipv4/Kconfig
[ ... ]
> @@ -113,9 +119,11 @@ config IP_ROUTE_VERBOSE
>
> config IP_ROUTE_CLASSID
> bool
> + depends on LEGACY_IP
IP_ROUTE_CLASSID is selected by NETFILTER_XT_MATCH_REALM in
net/netfilter/Kconfig and by NET_CLS_ROUTE4 in net/sched/Kconfig,
neither of which depends on LEGACY_IP.
Would this produce unmet direct dependency warnings when either of
those options is enabled with LEGACY_IP=n?
> @@ -190,6 +199,7 @@ config NET_IPIP
>
> config NET_IPGRE_DEMUX
> tristate "IP: GRE demultiplexer"
> + depends on LEGACY_IP
> help
> This is helper module to demultiplex GRE packets on GRE version field criteria.
> Required by ip_gre and pptp modules.
IPV6_GRE in net/ipv6/Kconfig has 'depends on NET_IPGRE_DEMUX'.
ip6_gre.c uses gre_parse_header() from the GRE demux module.
Gating NET_IPGRE_DEMUX on LEGACY_IP silently makes IPv6 GRE tunneling
unavailable on IPv6-only systems. Should this option be left ungated,
similar to NET_IP_TUNNEL?
[ ... ]
> @@ -226,10 +238,12 @@ config NET_IPGRE_BROADCAST
>
> config IP_MROUTE_COMMON
> bool
> + depends on LEGACY_IP
> depends on IP_MROUTE || IPV6_MROUTE
IP_MROUTE_COMMON is shared infrastructure between IPv4 and IPv6
multicast routing. ipmr_base.c describes itself as "Common logic
shared by IPv4 [ipmr] and IPv6 [ip6mr] implementation".
IPV6_MROUTE in net/ipv6/Kconfig does 'select IP_MROUTE_COMMON'
without depending on LEGACY_IP. When LEGACY_IP=n and IPV6_MROUTE=y,
this will produce an unmet dependency warning.
Should IP_MROUTE_COMMON be left ungated, like NET_IP_TUNNEL and the
other shared options listed in the commit message?
[ ... ]
> @@ -425,11 +449,13 @@ config INET_TABLE_PERTURB_ORDER
>
> config INET_XFRM_TUNNEL
> tristate
> + depends on LEGACY_IP
> select INET_TUNNEL
> default n
>
> config INET_TUNNEL
> tristate
> + depends on LEGACY_IP
> default n
IPV6_SIT in net/ipv6/Kconfig does 'select INET_TUNNEL' without
depending on LEGACY_IP. When LEGACY_IP=n and IPV6_SIT is enabled,
this will produce an unmet dependency warning for INET_TUNNEL.
SIT is inherently IPv4-dependent (IPv6-in-IPv4 tunneling), so perhaps
IPV6_SIT also needs 'depends on LEGACY_IP'?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23838411859
^ permalink raw reply
* Re: [PATCH 1/1] net: ipv6: flowlabel: defer exclusive option free until RCU teardown
From: Greg KH @ 2026-04-01 8:45 UTC (permalink / raw)
To: Yuan Tan
Cc: Eric Dumazet, kuniyu, Ren Wei, security, netdev, davem, dsahern,
kuba, pabeni, horms, afaerber, mani, yoshfuji, yifanwucs,
tomapufckgml, bird, enjou1224z, zcliangcn
In-Reply-To: <7c26a74d-90c5-4520-a10a-22f06e098b86@gmail.com>
On Wed, Apr 01, 2026 at 12:05:31AM -0700, Yuan Tan wrote:
> On 3/31/2026 6:05 PM, Eric Dumazet wrote:
> > On Tue, Mar 31, 2026 at 5:41 PM Yuan Tan <yuantan098@gmail.com> wrote:
> >> On 3/31/2026 1:52 AM, Eric Dumazet wrote:
> >> Finally, regarding our tags, our team has a clear division of
> >> labor—some focus on finding vulnerabilities, others on fixing them,
> >> followed by an internal review and testing before a dedicated
> >> member handles community outreach.
> >>
> > You included 8 tags, this seems a bit too much for such a small patch.
> CC Greg here, as he knows a bit about our team's background.
Yeah, 8 tags "seems" like a lot, but for a team that is working on
these things, I think that is good, a bunch of people are wanting to be
on the "path of blame if something went wrong" which is nice to see,
they aren't just dumping the responsibility onto one person :)
So I don't have any objection to this at all, and in fact, welcome it.
> Our team has developed a tool that found hundreds of non-root bugs with
> PoCs. We want to ensure these are fixed properly and quickly rather than
> dumping reports onto the mailing list and hoping for others to find the
> time to fix. So we have organized a group of promising students. As some of
> them are new to kernel development, we have been providing hands-on
> mentorship to guide them through the process.
This is a good thing, thanks for doing this, it is helping both the
kernel out in getting these things fixed, and these students to get them
great experience in working upstream in a proper way.
This is great stuff, I wish more professors and schools would do this.
thanks,
greg k-h
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net-next v4 1/2] e1000e: add basic XDP support
From: Loktionov, Aleksandr @ 2026-04-01 8:48 UTC (permalink / raw)
To: Matteo Croce, Nguyen, Anthony L, Kitszel, Przemyslaw, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Alexei Starovoitov, Daniel Borkmann, Jesper Dangaard Brouer,
John Fastabend, Mohsin Bashir
Cc: netdev@vger.kernel.org, bpf@vger.kernel.org,
intel-wired-lan@lists.osuosl.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260323182823.5813-2-teknoraver@meta.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Matteo Croce
> Sent: Monday, March 23, 2026 7:28 PM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; Andrew Lunn
> <andrew+netdev@lunn.ch>; David S. Miller <davem@davemloft.net>; Eric
> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>; Alexei Starovoitov <ast@kernel.org>; Daniel
> Borkmann <daniel@iogearbox.net>; Jesper Dangaard Brouer
> <hawk@kernel.org>; John Fastabend <john.fastabend@gmail.com>; Mohsin
> Bashir <mohsin.bashr@gmail.com>
> Cc: netdev@vger.kernel.org; bpf@vger.kernel.org; intel-wired-
> lan@lists.osuosl.org; linux-kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH net-next v4 1/2] e1000e: add basic
> XDP support
>
> Add XDP support to the e1000e driver covering the actions defined by
> NETDEV_XDP_ACT_BASIC: XDP_DROP, XDP_PASS, XDP_TX and XDP_ABORTED.
>
> Infrastructure:
...
> +/**
> + * e1000_xdp_setup - add/remove an XDP program
> + * @netdev: network interface device structure
> + * @bpf: XDP program setup structure
> + **/
> +static int e1000_xdp_setup(struct net_device *netdev, struct
> netdev_bpf
> +*bpf) {
> + struct e1000_adapter *adapter = netdev_priv(netdev);
> + struct bpf_prog *prog = bpf->prog, *old_prog;
> + bool running = netif_running(netdev);
> + bool need_reset;
> +
> + /* XDP is incompatible with jumbo frames */
> + if (prog && netdev->mtu > ETH_DATA_LEN) {
> + NL_SET_ERR_MSG_MOD(bpf->extack,
> + "XDP is not supported with jumbo
> frames");
> + return -EINVAL;
> + }
> +
> + /* Validate frame fits in a single page with XDP headroom */
> + if (prog && netdev->mtu + VLAN_ETH_HLEN + ETH_FCS_LEN +
> + XDP_PACKET_HEADROOM > PAGE_SIZE) {
> + NL_SET_ERR_MSG_MOD(bpf->extack,
> + "Frame size too large for XDP");
> + return -EINVAL;
> + }
> +
> + old_prog = xchg(&adapter->xdp_prog, prog);
> + need_reset = (!!prog != !!old_prog);
> +
> + /* Transition between XDP and non-XDP requires ring
> reconfiguration */
> + if (need_reset && running)
> + e1000e_close(netdev);
> +
> + if (old_prog)
> + bpf_prog_put(old_prog);
> +
> + if (!need_reset)
> + return 0;
> +
> + if (running) {
> + int err = e1000e_open(netdev);
> +
> + if (err) {
> + /* Remove the XDP program since interface is down
> */
> + xchg(&adapter->xdp_prog, NULL);
> + if (prog)
> + bpf_prog_put(prog);
I'm afraid the reference is owned by the BPF infrastructure, and you will drop refcount to 0.
> + return err;
> + }
> + }
> +
> + return 0;
> +}
...
> kfree(adapter->tx_ring);
> kfree(adapter->rx_ring);
>
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH 1/2 net v2] ipv4: nexthop: avoid duplicate NHA_HW_STATS_ENABLE on nexthop group dump
From: Eric Dumazet @ 2026-04-01 8:53 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: netdev, idosch, petrm, horms, pabeni, kuba, davem, dsahern, kees
In-Reply-To: <20260401081741.4273-1-fmancera@suse.de>
On Wed, Apr 1, 2026 at 1:17 AM Fernando Fernandez Mancera
<fmancera@suse.de> wrote:
>
> Currently NHA_HW_STATS_ENABLE is included twice everytime a dump of
> nexthop group is performed with NHA_OP_FLAG_DUMP_STATS. As all the stats
> querying were moved to nla_put_nh_group_stats(), leave only that
> instance of the attribute querying.
>
> Fixes: 5072ae00aea4 ("net: nexthop: Expose nexthop group HW stats to user space")
> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Eric Dumazet <edumazet@google.com>
^ permalink raw reply
* Re: [PATCH 2/2 net v2] ipv4: nexthop: allocate skb dynamically in rtm_get_nexthop()
From: Eric Dumazet @ 2026-04-01 8:59 UTC (permalink / raw)
To: Fernando Fernandez Mancera
Cc: netdev, idosch, petrm, horms, pabeni, kuba, davem, dsahern, kees,
Yiming Qian
In-Reply-To: <20260401081741.4273-2-fmancera@suse.de>
On Wed, Apr 1, 2026 at 1:17 AM Fernando Fernandez Mancera
<fmancera@suse.de> wrote:
>
> When querying a nexthop object via RTM_GETNEXTHOP, the kernel currently
> allocates a fixed-size skb using NLMSG_GOODSIZE. While sufficient for
> single nexthops and small Equal-Cost Multi-Path groups, this fixed
> allocation fails for large nexthop groups like 512 nexthops.
>
> This results in the following warning splat:
>
> WARNING: net/ipv4/nexthop.c:3395 at rtm_get_nexthop+0x176/0x1c0, CPU#20: rep/4608
> [...]
> RIP: 0010:rtm_get_nexthop (net/ipv4/nexthop.c:3395)
> [...]
> Call Trace:
> <TASK>
> rtnetlink_rcv_msg (net/core/rtnetlink.c:6989)
> netlink_rcv_skb (net/netlink/af_netlink.c:2550)
> netlink_unicast (net/netlink/af_netlink.c:1319 net/netlink/af_netlink.c:1344)
> netlink_sendmsg (net/netlink/af_netlink.c:1894)
> ____sys_sendmsg (net/socket.c:721 net/socket.c:736 net/socket.c:2585)
> ___sys_sendmsg (net/socket.c:2641)
> __sys_sendmsg (net/socket.c:2671)
> do_syscall_64 (arch/x86/entry/syscall_64.c:63 arch/x86/entry/syscall_64.c:94)
> entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
> </TASK>
>
> Fix this by allocating the size dynamically using nh_nlmsg_size() and
> using nlmsg_new(), this is consistent with nexthop_notify() behavior. In
> addition, adjust nh_nlmsg_size_grp() so it calculates the size needed
> based on flags passed.
>
> This cannot be reproduced via iproute2 as the group size is currently
> limited and the command fails as follows:
>
> addattr_l ERROR: message exceeded bound of 1048
>
> Fixes: 430a049190de ("nexthop: Add support for nexthop groups")
> Reported-by: Yiming Qian <yimingqian591@gmail.com>
> Closes: https://lore.kernel.org/netdev/CAL_bE8Li2h4KO+AQFXW4S6Yb_u5X4oSKnkywW+LPFjuErhqELA@mail.gmail.com/
> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Thanks !
^ permalink raw reply
* Re: [PATCH 2/6] net: Add CONFIG_LEGACY_IP option
From: bot+bpf-ci @ 2026-04-01 9:01 UTC (permalink / raw)
To: dwmw2, saeedm, leon, tariqt, mbloch, andrew+netdev, davem,
edumazet, kuba, pabeni, horms, razor, idosch, martin.lau, daniel,
john.fastabend, sdf, ast, andrii, eddyz87, song, yonghong.song,
kpsingh, haoluo, jolsa, kuniyu, willemb, dsahern, ncardwell,
johannes, pablo, fw, phil, gnault, dwmw, kees, alazar, gal, paul,
netdev, linux-rdma, linux-kernel, oss-drivers, bridge, bpf,
linux-wireless, netfilter-devel, coreteam, torvalds,
jon.maddog.hall
Cc: ast, andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260401074509.1897527-3-dwmw2@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1848 bytes --]
> This is the first step toward making Legacy IP optional. The option
> defaults to y and currently has no effect — subsequent patches will use
> it to guard IPv4 entry points.
The commit message says "The option defaults to y", but the Kconfig
entry has no "default y" line. A bool without an explicit default
is n in Kconfig, so LEGACY_IP will be disabled on any fresh config
built with make defconfig or make olddefconfig.
Later patches in this series (be2f051150f9, f04a0717c27d) add
"depends on LEGACY_IP" to all IPv4-specific Kconfig symbols and guard
IPv4 entry points in C code. With LEGACY_IP defaulting to n, those
patches will silently disable IPv4 networking for any newly generated
kernel configuration.
Should the Kconfig entry include "default y" to match the stated
intent?
> diff --git a/net/ipv4/Kconfig b/net/ipv4/Kconfig
> index df922f9f5289..aef2c5349e62 100644
> --- a/net/ipv4/Kconfig
> +++ b/net/ipv4/Kconfig
> @@ -2,6 +2,17 @@
> #
> # IP configuration
> #
> +config LEGACY_IP
> + bool "The IPv4 protocol (Legacy IP)"
> + help
> + Support for IP version 4 (IPv4).
> +
> + Legacy IP is the protocol used by the early ARPANET, before IPv6
> + was standardised in the final decade of the 1900s. It should only
> + be necessary these days to interoperate with legacy networks.
> +
> + If unsure, say N.
The help text says "If unsure, say N." Combined with the missing
default, this guides users to disable IPv4. If the intent is a
backward-compatible introduction where IPv4 stays enabled unless
explicitly turned off, this should probably be "If unsure, say Y."
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23838411859
^ permalink raw reply
* Re: [PATCH 5/6] net: Change CONFIG_INET to CONFIG_LEGACY_IP for IPv4-only code
From: bot+bpf-ci @ 2026-04-01 9:01 UTC (permalink / raw)
To: dwmw2, saeedm, leon, tariqt, mbloch, andrew+netdev, davem,
edumazet, kuba, pabeni, horms, razor, idosch, martin.lau, daniel,
john.fastabend, sdf, ast, andrii, eddyz87, song, yonghong.song,
kpsingh, haoluo, jolsa, kuniyu, willemb, dsahern, ncardwell,
johannes, pablo, fw, phil, gnault, dwmw, kees, alazar, gal, paul,
netdev, linux-rdma, linux-kernel, oss-drivers, bridge, bpf,
linux-wireless, netfilter-devel, coreteam, torvalds,
jon.maddog.hall
Cc: ast, andrii, daniel, martin.lau, eddyz87, yonghong.song, clm,
ihor.solodrai
In-Reply-To: <20260401074509.1897527-6-dwmw2@infradead.org>
[-- Attachment #1: Type: text/plain, Size: 1268 bytes --]
> diff --git a/net/core/filter.c b/net/core/filter.c
> index ad71ceefcb5e..ef99bd9fddd6 100644
> --- a/net/core/filter.c
> +++ b/net/core/filter.c
[ ... ]
> @@ -6095,7 +6095,7 @@ static int bpf_fib_set_fwd_params(struct bpf_fib_lookup *params, u32 mtu)
> }
> #endif
>
> -#if IS_ENABLED(CONFIG_INET)
> +#if IS_ENABLED(CONFIG_LEGACY_IP)
> static int bpf_ipv4_fib_lookup(struct net *net, struct bpf_fib_lookup *params,
> u32 flags, bool check_mtu)
bpf_fib_set_fwd_params() above this hunk is still guarded by
CONFIG_INET, and its only two callers are bpf_ipv4_fib_lookup()
(now CONFIG_LEGACY_IP) and bpf_ipv6_fib_lookup() (CONFIG_IPV6).
When CONFIG_INET=y with both CONFIG_LEGACY_IP=n and CONFIG_IPV6=n,
bpf_fib_set_fwd_params() becomes an unused static function, which
will produce a -Wunused-function warning and break CONFIG_WERROR
builds.
Should the guard on bpf_fib_set_fwd_params() be changed to
something like:
#if IS_ENABLED(CONFIG_LEGACY_IP) || IS_ENABLED(CONFIG_IPV6)
to match its actual callers?
---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md
CI run summary: https://github.com/kernel-patches/bpf/actions/runs/23838411859
^ permalink raw reply
* Re: [PATCH v8 02/10] x86/bhi: Make clear_bhb_loop() effective on newer CPUs
From: David Laight @ 2026-04-01 9:02 UTC (permalink / raw)
To: Pawan Gupta
Cc: Borislav Petkov, x86, Jon Kohler, Nikolay Borisov, H. Peter Anvin,
Josh Poimboeuf, David Kaplan, Sean Christopherson, Dave Hansen,
Peter Zijlstra, Alexei Starovoitov, Daniel Borkmann,
Andrii Nakryiko, KP Singh, Jiri Olsa, David S. Miller,
Andy Lutomirski, Thomas Gleixner, Ingo Molnar, David Ahern,
Martin KaFai Lau, Eduard Zingerman, Song Liu, Yonghong Song,
John Fastabend, Stanislav Fomichev, Hao Luo, Paolo Bonzini,
Jonathan Corbet, linux-kernel, kvm, Asit Mallick, Tao Zhang, bpf,
netdev, linux-doc
In-Reply-To: <20260401081236.3rjp2wigkr6w3nym@desk>
On Wed, 1 Apr 2026 01:12:36 -0700
Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote:
> On Sat, Mar 28, 2026 at 10:08:37AM +0000, David Laight wrote:
> > On Fri, 27 Mar 2026 17:42:56 -0700
> > Pawan Gupta <pawan.kumar.gupta@linux.intel.com> wrote:
> >
> > > On Thu, Mar 26, 2026 at 01:29:31PM -0700, Pawan Gupta wrote:
> > > > On Thu, Mar 26, 2026 at 10:45:57AM +0000, David Laight wrote:
> > > > > On Thu, 26 Mar 2026 11:01:20 +0100
> > > > > Borislav Petkov <bp@alien8.de> wrote:
> > > > >
> > > > > > On Thu, Mar 26, 2026 at 01:39:34AM -0700, Pawan Gupta wrote:
> > > > > > > I believe the equivalent for cpu_feature_enabled() in asm is the
> > > > > > > ALTERNATIVE. Please let me know if I am missing something.
> > > > > >
> > > > > > Yes, you are.
> > > > > >
> > > > > > The point is that you don't want to stick those alternative calls inside some
> > > > > > magic bhb_loop function but hand them in from the outside, as function
> > > > > > arguments.
> > > > > >
> > > > > > Basically what I did.
> > > > > >
> > > > > > Then you were worried about this being C code and it had to be noinstr... So
> > > > > > that outer function can be rewritten in asm, I think, and still keep it well
> > > > > > separate.
> > > > > >
> > > > > > I'll try to rewrite it once I get a free minute, and see how it looks.
> > > > > >
> > > > >
> > > > > I think someone tried getting C code to write the values to global data
> > > > > and getting the asm to read them.
> > > > > That got discounted because it spilt things between two largely unrelated files.
> > > >
> > > >
> > > > The implementation with global variables wasn't that bad, let me revive it.
> > > >
> > > > This part which ties sequence to BHI mitigation, which is not ideal,
> > > > (because VMSCAPE also uses it) it does seems a cleaner option.
> > > >
> > > > --- a/arch/x86/kernel/cpu/bugs.c
> > > > +++ b/arch/x86/kernel/cpu/bugs.c
> > > > @@ -2095,6 +2095,11 @@ static void __init bhi_select_mitigation(void)
> > > >
> > > > static void __init bhi_update_mitigation(void)
> > > > {
> > > > + if (!cpu_feature_enabled(X86_FEATURE_BHI_CTRL)) {
> > > > + bhi_seq_outer_loop = 5;
> > > > + bhi_seq_inner_loop = 5;
> > > > + }
> > > > +
> > > >
> > > > I believe this can be moved to somewhere common to all mitigations.
> > > >
> > > > > I think the BPF code would need significant refactoring to call a C function.
> > > >
> > > > Ya, true. Will use globals and keep clear_bhb_loop() in asm.
> > >
> > > While testing this approach, I noticed that syscalls were suffering an 8%
> > > regression on ICX for Native BHI mitigation:
> > >
> > > $ perf bench syscall basic -l 100000000
> > >
> > > Bisection pointed to the change for using 8-bit registers (al/ah replacing
> > > eax/ecx) as the main contributor to the regression. (Global variables added
> > > a bit, but within noise).
> > >
> > > Further digging revealed a strange behavior, using %ah for the inner loop
> > > was causing the regression, interchanging %al and %ah in the loops
> > > (for movb and sub) eliminated the regression.
> > >
> > > <clear_bhb_loop_nofence>:
> > >
> > > movb bhb_seq_outer_loop(%rip), %al
> > >
> > > call 1f
> > > jmp 5f
> > > 1: call 2f
> > > .Lret1: RET
> > > 2: movb bhb_seq_inner_loop(%rip), %ah
> > > 3: jmp 4f
> > > nop
> > > 4: sub $1, %ah <---- No regression with %al here
> > > jnz 3b
> > > sub $1, %al
> > > jnz 1b
> > >
> > > My guess is, "sub $1, %al" is faster than "sub $1, %ah". Using %al in the
> > > inner loop, which is executed more number of times is likely making the
> > > difference. A perf profile is needed to confirm this.
> >
> > I bet it is also CPU dependant - it is quite likely that there isn't
> > any special hardware to support partial writes of %ah so it ends up taking
> > a slow path (possibly even a microcoded one to get an 8% regression).
>
> Strangely, %ah in the inner loop incurs less uops and has fewer branch
> misses, yet takes more cycles. Below is the perf data for the sequence on a
> Rocket Lake (similar observation on ICX and EMR):
>
> Event %al inner %ah inner Delta
> ---------------------- ------------- ------------- ----------
> cycles 776,775,020 972,322,384 +25.2%
> instructions/cycle 1.23 0.98 -20.3%
> branch-misses 4,792,502 560,449 -88.3%
> uops_issued.any 768,019,010 696,888,357 -9.3%
> time elapsed 0.1627s 0.2048s +25.9%
>
> Time elapsed directly correlates with the increase in cycles.
That might be consistent with the %ah accesses (probably writes)
being very slow/synchronising.
So you are getting a full cpu stall instead speculative execution
of the following instructions - which must include a lot of mis-predicted
branches.
> > As well as swapping %al <-> %ah try changing the outer loop decrement to
> > sub $0x100, %ax
> > since %al is zero that will set the z flag the same.
>
> Unfortunately, using "sub $0x100, %ax"(with %al as inner loop) isn't better
> than just using "sub $1, %ah" in the outer loop:
>
> Event %al inner + sub %ax Delta
> ---------------------- ------------- ------------- ----------
> cycles 776,775,020 813,372,036 +4.7%
> instructions/cycle 1.23 1.17 -4.5%
> branch-misses 4,792,502 7,610,323 +58.8%
> uops_issued.any 768,019,010 827,465,137 +7.7%
> time elapsed 0.1627s 0.1707s +4.9%
That is even more interesting.
The 'sub %ax' version has more uops and more branch-misses.
Looks like the extra cost of the %ah access is less than the cost
of the extra mis-predicted branches.
Makes me wonder where a version that uses %cl fits?
(Or use a zero-extending read and %eax/%ecx - likely to be the same.)
I'll bet 'one beer' that is nearest the 'sub %ax' version.
David
>
> > I've just hacked a test into some test code I've got.
> > I'm not seeing an unexpected costs on either zen-5 or haswell.
> > So it may be more subtle.
>
> This is puzzling, but atleast it is evident that using %al for the inner
> loop seems to be the best option. In summary:
>
> Variant Cycles Uops Issued Branch Misses
> ------- ---------- ----------- -------------
> %al 776M 768M 4.8M (fastest)
> %ah 972M (+25%) 697M (-9%) 560K (-88%) (fewer uops + misses, yet slowest)
> sub %ax 813M (+5%) 827M (+8%) 7.6M (+59%) (most uops + misses)
^ 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