* [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf)
@ 2025-10-02 0:14 Jacob Keller
2025-10-02 0:14 ` [PATCH net 1/8] idpf: cleanup remaining SKBs in PTP flows Jacob Keller
` (9 more replies)
0 siblings, 10 replies; 21+ messages in thread
From: Jacob Keller @ 2025-10-02 0:14 UTC (permalink / raw)
To: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Emil Tantilov, Pavan Kumar Linga,
Alexander Lobakin, Willem de Bruijn, Sridhar Samudrala,
Phani Burra, Piotr Kwapulinski, Simon Horman, Radoslaw Tyl,
Jedrzej Jagielski, Mateusz Polchlopek
Cc: Anton Nadezhdin, Konstantin Ilichev, Milena Olech, netdev,
linux-kernel, Jacob Keller, Aleksandr Loktionov, Samuel Salin,
Chittim Madhu, Joshua Hay, Andrzej Wilczynski, stable,
Rafal Romanowski, Koichiro Den, Rinitha S, Paul Menzel
For idpf:
Milena fixes a memory leak in the idpf reset logic when the driver resets
with an outstanding Tx timestamp.
Emil fixes a race condition in idpf_vport_stop() by using
test_and_clear_bit() to ensure we execute idpf_vport_stop() once.
For ixgbe and ixgbevf:
Jedrzej fixes an issue with reporting link speed on E610 VFs.
Jedrzej also fixes the VF mailbox API incompatibilities caused by the
confusion with API v1.4, v1.5, and v1.6. The v1.4 API introduced IPSEC
offload, but this was only supported on Linux hosts. The v1.5 API
introduced a new mailbox API which is necessary to resolve issues on ESX
hosts. The v1.6 API introduced a new link management API for E610. Jedrzej
introduces a new v1.7 API with a feature negotiation which enables properly
checking if features such as IPSEC or the ESX mailbox APIs are supported.
This resolves issues with compatibility on different hosts, and aligns the
API across hosts instead of having Linux require custom mailbox API
versions for IPSEC offload.
Koichiro fixes a KASAN use-after-free bug in ixgbe_remove().
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
---
Emil Tantilov (2):
idpf: convert vport state to bitmap
idpf: fix possible race in idpf_vport_stop()
Jedrzej Jagielski (4):
ixgbevf: fix getting link speed data for E610 devices
ixgbe: handle IXGBE_VF_GET_PF_LINK_STATE mailbox operation
ixgbevf: fix mailbox API compatibility by negotiating supported features
ixgbe: handle IXGBE_VF_FEATURES_NEGOTIATE mbox cmd
Koichiro Den (1):
ixgbe: fix too early devlink_free() in ixgbe_remove()
Milena Olech (1):
idpf: cleanup remaining SKBs in PTP flows
drivers/net/ethernet/intel/idpf/idpf.h | 12 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 15 ++
drivers/net/ethernet/intel/ixgbevf/defines.h | 1 +
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 7 +
drivers/net/ethernet/intel/ixgbevf/mbx.h | 8 +
drivers/net/ethernet/intel/ixgbevf/vf.h | 1 +
drivers/net/ethernet/intel/idpf/idpf_ethtool.c | 10 +-
drivers/net/ethernet/intel/idpf/idpf_lib.c | 23 ++-
drivers/net/ethernet/intel/idpf/idpf_ptp.c | 3 +
.../net/ethernet/intel/idpf/idpf_singleq_txrx.c | 2 +-
drivers/net/ethernet/intel/idpf/idpf_txrx.c | 2 +-
drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 4 +-
.../net/ethernet/intel/idpf/idpf_virtchnl_ptp.c | 1 +
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 79 +++++++++
drivers/net/ethernet/intel/ixgbevf/ipsec.c | 10 ++
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 34 +++-
drivers/net/ethernet/intel/ixgbevf/vf.c | 182 +++++++++++++++++----
18 files changed, 335 insertions(+), 62 deletions(-)
---
base-commit: daa26ea63c6f848159821cd9b3cbe47cddbb0a1c
change-id: 20251001-jk-iwl-net-2025-10-01-92cd2a626ff7
Best regards,
--
Jacob Keller <jacob.e.keller@intel.com>
^ permalink raw reply [flat|nested] 21+ messages in thread
* [PATCH net 1/8] idpf: cleanup remaining SKBs in PTP flows
2025-10-02 0:14 [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf) Jacob Keller
@ 2025-10-02 0:14 ` Jacob Keller
2025-10-02 0:14 ` [PATCH net 2/8] idpf: convert vport state to bitmap Jacob Keller
` (8 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: Jacob Keller @ 2025-10-02 0:14 UTC (permalink / raw)
To: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Emil Tantilov, Pavan Kumar Linga,
Alexander Lobakin, Willem de Bruijn, Sridhar Samudrala,
Phani Burra, Piotr Kwapulinski, Simon Horman, Radoslaw Tyl,
Jedrzej Jagielski, Mateusz Polchlopek
Cc: Anton Nadezhdin, Konstantin Ilichev, Milena Olech, netdev,
linux-kernel, Jacob Keller, Aleksandr Loktionov, Samuel Salin
From: Milena Olech <milena.olech@intel.com>
When the driver requests Tx timestamp value, one of the first steps is
to clone SKB using skb_get. It increases the reference counter for that
SKB to prevent unexpected freeing by another component.
However, there may be a case where the index is requested, SKB is
assigned and never consumed by PTP flows - for example due to reset during
running PTP apps.
Add a check in release timestamping function to verify if the SKB
assigned to Tx timestamp latch was freed, and release remaining SKBs.
Fixes: 4901e83a94ef ("idpf: add Tx timestamp capabilities negotiation")
Signed-off-by: Milena Olech <milena.olech@intel.com>
Signed-off-by: Anton Nadezhdin <anton.nadezhdin@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
---
drivers/net/ethernet/intel/idpf/idpf_ptp.c | 3 +++
drivers/net/ethernet/intel/idpf/idpf_virtchnl_ptp.c | 1 +
2 files changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/intel/idpf/idpf_ptp.c b/drivers/net/ethernet/intel/idpf/idpf_ptp.c
index ee21f2ff0cad..63a41e688733 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_ptp.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_ptp.c
@@ -855,6 +855,9 @@ static void idpf_ptp_release_vport_tstamp(struct idpf_vport *vport)
head = &vport->tx_tstamp_caps->latches_in_use;
list_for_each_entry_safe(ptp_tx_tstamp, tmp, head, list_member) {
list_del(&ptp_tx_tstamp->list_member);
+ if (ptp_tx_tstamp->skb)
+ consume_skb(ptp_tx_tstamp->skb);
+
kfree(ptp_tx_tstamp);
}
diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl_ptp.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl_ptp.c
index 4f1fb0cefe51..688a6f4e0acc 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl_ptp.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl_ptp.c
@@ -517,6 +517,7 @@ idpf_ptp_get_tstamp_value(struct idpf_vport *vport,
shhwtstamps.hwtstamp = ns_to_ktime(tstamp);
skb_tstamp_tx(ptp_tx_tstamp->skb, &shhwtstamps);
consume_skb(ptp_tx_tstamp->skb);
+ ptp_tx_tstamp->skb = NULL;
list_add(&ptp_tx_tstamp->list_member,
&tx_tstamp_caps->latches_free);
--
2.51.0.rc1.197.g6d975e95c9d7
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH net 2/8] idpf: convert vport state to bitmap
2025-10-02 0:14 [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf) Jacob Keller
2025-10-02 0:14 ` [PATCH net 1/8] idpf: cleanup remaining SKBs in PTP flows Jacob Keller
@ 2025-10-02 0:14 ` Jacob Keller
2025-10-02 0:14 ` [PATCH net 3/8] idpf: fix possible race in idpf_vport_stop() Jacob Keller
` (7 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: Jacob Keller @ 2025-10-02 0:14 UTC (permalink / raw)
To: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Emil Tantilov, Pavan Kumar Linga,
Alexander Lobakin, Willem de Bruijn, Sridhar Samudrala,
Phani Burra, Piotr Kwapulinski, Simon Horman, Radoslaw Tyl,
Jedrzej Jagielski, Mateusz Polchlopek
Cc: Anton Nadezhdin, Konstantin Ilichev, Milena Olech, netdev,
linux-kernel, Jacob Keller, Aleksandr Loktionov, Chittim Madhu,
Samuel Salin
From: Emil Tantilov <emil.s.tantilov@intel.com>
Convert vport state to a bitmap and remove the DOWN state which is
redundant in the existing logic. There are no functional changes aside
from the use of bitwise operations when setting and checking the states.
Removed the double underscore to be consistent with the naming of other
bitmaps in the header and renamed current_state to vport_is_up to match
the meaning of the new variable.
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Chittim Madhu <madhu.chittim@intel.com>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
---
drivers/net/ethernet/intel/idpf/idpf.h | 12 +++++------
drivers/net/ethernet/intel/idpf/idpf_ethtool.c | 10 ++++-----
drivers/net/ethernet/intel/idpf/idpf_lib.c | 24 +++++++++++-----------
.../net/ethernet/intel/idpf/idpf_singleq_txrx.c | 2 +-
drivers/net/ethernet/intel/idpf/idpf_txrx.c | 2 +-
drivers/net/ethernet/intel/idpf/idpf_virtchnl.c | 4 ++--
6 files changed, 26 insertions(+), 28 deletions(-)
diff --git a/drivers/net/ethernet/intel/idpf/idpf.h b/drivers/net/ethernet/intel/idpf/idpf.h
index f4c0eaf9bde3..cfbf3a716f34 100644
--- a/drivers/net/ethernet/intel/idpf/idpf.h
+++ b/drivers/net/ethernet/intel/idpf/idpf.h
@@ -130,14 +130,12 @@ enum idpf_cap_field {
/**
* enum idpf_vport_state - Current vport state
- * @__IDPF_VPORT_DOWN: Vport is down
- * @__IDPF_VPORT_UP: Vport is up
- * @__IDPF_VPORT_STATE_LAST: Must be last, number of states
+ * @IDPF_VPORT_UP: Vport is up
+ * @IDPF_VPORT_STATE_NBITS: Must be last, number of states
*/
enum idpf_vport_state {
- __IDPF_VPORT_DOWN,
- __IDPF_VPORT_UP,
- __IDPF_VPORT_STATE_LAST,
+ IDPF_VPORT_UP,
+ IDPF_VPORT_STATE_NBITS
};
/**
@@ -159,7 +157,7 @@ struct idpf_netdev_priv {
u32 link_speed_mbps;
u16 vport_idx;
u16 max_tx_hdr_size;
- enum idpf_vport_state state;
+ DECLARE_BITMAP(state, IDPF_VPORT_STATE_NBITS);
struct rtnl_link_stats64 netstats;
spinlock_t stats_lock;
};
diff --git a/drivers/net/ethernet/intel/idpf/idpf_ethtool.c b/drivers/net/ethernet/intel/idpf/idpf_ethtool.c
index 0eb812ac19c2..f84e247399a7 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_ethtool.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_ethtool.c
@@ -386,7 +386,7 @@ static int idpf_get_rxfh(struct net_device *netdev,
}
rss_data = &adapter->vport_config[np->vport_idx]->user_config.rss_data;
- if (np->state != __IDPF_VPORT_UP)
+ if (!test_bit(IDPF_VPORT_UP, np->state))
goto unlock_mutex;
rxfh->hfunc = ETH_RSS_HASH_TOP;
@@ -436,7 +436,7 @@ static int idpf_set_rxfh(struct net_device *netdev,
}
rss_data = &adapter->vport_config[vport->idx]->user_config.rss_data;
- if (np->state != __IDPF_VPORT_UP)
+ if (!test_bit(IDPF_VPORT_UP, np->state))
goto unlock_mutex;
if (rxfh->hfunc != ETH_RSS_HASH_NO_CHANGE &&
@@ -1167,7 +1167,7 @@ static void idpf_get_ethtool_stats(struct net_device *netdev,
idpf_vport_ctrl_lock(netdev);
vport = idpf_netdev_to_vport(netdev);
- if (np->state != __IDPF_VPORT_UP) {
+ if (!test_bit(IDPF_VPORT_UP, np->state)) {
idpf_vport_ctrl_unlock(netdev);
return;
@@ -1319,7 +1319,7 @@ static int idpf_get_q_coalesce(struct net_device *netdev,
idpf_vport_ctrl_lock(netdev);
vport = idpf_netdev_to_vport(netdev);
- if (np->state != __IDPF_VPORT_UP)
+ if (!test_bit(IDPF_VPORT_UP, np->state))
goto unlock_mutex;
if (q_num >= vport->num_rxq && q_num >= vport->num_txq) {
@@ -1507,7 +1507,7 @@ static int idpf_set_coalesce(struct net_device *netdev,
idpf_vport_ctrl_lock(netdev);
vport = idpf_netdev_to_vport(netdev);
- if (np->state != __IDPF_VPORT_UP)
+ if (!test_bit(IDPF_VPORT_UP, np->state))
goto unlock_mutex;
for (i = 0; i < vport->num_txq; i++) {
diff --git a/drivers/net/ethernet/intel/idpf/idpf_lib.c b/drivers/net/ethernet/intel/idpf/idpf_lib.c
index 513032cb5f08..89d30c395533 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_lib.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_lib.c
@@ -517,7 +517,7 @@ static int idpf_del_mac_filter(struct idpf_vport *vport,
}
spin_unlock_bh(&vport_config->mac_filter_list_lock);
- if (np->state == __IDPF_VPORT_UP) {
+ if (test_bit(IDPF_VPORT_UP, np->state)) {
int err;
err = idpf_add_del_mac_filters(vport, np, false, async);
@@ -588,7 +588,7 @@ static int idpf_add_mac_filter(struct idpf_vport *vport,
if (err)
return err;
- if (np->state == __IDPF_VPORT_UP)
+ if (test_bit(IDPF_VPORT_UP, np->state))
err = idpf_add_del_mac_filters(vport, np, true, async);
return err;
@@ -888,7 +888,7 @@ static void idpf_vport_stop(struct idpf_vport *vport)
{
struct idpf_netdev_priv *np = netdev_priv(vport->netdev);
- if (np->state <= __IDPF_VPORT_DOWN)
+ if (!test_bit(IDPF_VPORT_UP, np->state))
return;
netif_carrier_off(vport->netdev);
@@ -911,7 +911,7 @@ static void idpf_vport_stop(struct idpf_vport *vport)
idpf_vport_intr_deinit(vport);
idpf_vport_queues_rel(vport);
idpf_vport_intr_rel(vport);
- np->state = __IDPF_VPORT_DOWN;
+ clear_bit(IDPF_VPORT_UP, np->state);
}
/**
@@ -1332,7 +1332,7 @@ static int idpf_up_complete(struct idpf_vport *vport)
netif_tx_start_all_queues(vport->netdev);
}
- np->state = __IDPF_VPORT_UP;
+ set_bit(IDPF_VPORT_UP, np->state);
return 0;
}
@@ -1377,7 +1377,7 @@ static int idpf_vport_open(struct idpf_vport *vport)
struct idpf_vport_config *vport_config;
int err;
- if (np->state != __IDPF_VPORT_DOWN)
+ if (test_bit(IDPF_VPORT_UP, np->state))
return -EBUSY;
/* we do not allow interface up just yet */
@@ -1569,7 +1569,7 @@ void idpf_init_task(struct work_struct *work)
/* Once state is put into DOWN, driver is ready for dev_open */
np = netdev_priv(vport->netdev);
- np->state = __IDPF_VPORT_DOWN;
+ clear_bit(IDPF_VPORT_UP, np->state);
if (test_and_clear_bit(IDPF_VPORT_UP_REQUESTED, vport_config->flags))
idpf_vport_open(vport);
@@ -1768,7 +1768,7 @@ static void idpf_set_vport_state(struct idpf_adapter *adapter)
continue;
np = netdev_priv(adapter->netdevs[i]);
- if (np->state == __IDPF_VPORT_UP)
+ if (test_bit(IDPF_VPORT_UP, np->state))
set_bit(IDPF_VPORT_UP_REQUESTED,
adapter->vport_config[i]->flags);
}
@@ -1906,7 +1906,7 @@ int idpf_initiate_soft_reset(struct idpf_vport *vport,
enum idpf_vport_reset_cause reset_cause)
{
struct idpf_netdev_priv *np = netdev_priv(vport->netdev);
- enum idpf_vport_state current_state = np->state;
+ bool vport_is_up = test_bit(IDPF_VPORT_UP, np->state);
struct idpf_adapter *adapter = vport->adapter;
struct idpf_vport *new_vport;
int err;
@@ -1957,7 +1957,7 @@ int idpf_initiate_soft_reset(struct idpf_vport *vport,
goto free_vport;
}
- if (current_state <= __IDPF_VPORT_DOWN) {
+ if (!vport_is_up) {
idpf_send_delete_queues_msg(vport);
} else {
set_bit(IDPF_VPORT_DEL_QUEUES, vport->flags);
@@ -1990,7 +1990,7 @@ int idpf_initiate_soft_reset(struct idpf_vport *vport,
if (err)
goto err_open;
- if (current_state == __IDPF_VPORT_UP)
+ if (vport_is_up)
err = idpf_vport_open(vport);
goto free_vport;
@@ -2000,7 +2000,7 @@ int idpf_initiate_soft_reset(struct idpf_vport *vport,
vport->num_rxq, vport->num_bufq);
err_open:
- if (current_state == __IDPF_VPORT_UP)
+ if (vport_is_up)
idpf_vport_open(vport);
free_vport:
diff --git a/drivers/net/ethernet/intel/idpf/idpf_singleq_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_singleq_txrx.c
index b19b462e0bb6..06199fde3b57 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_singleq_txrx.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_singleq_txrx.c
@@ -571,7 +571,7 @@ static bool idpf_tx_singleq_clean(struct idpf_tx_queue *tx_q, int napi_budget,
np = netdev_priv(tx_q->netdev);
nq = netdev_get_tx_queue(tx_q->netdev, tx_q->idx);
- dont_wake = np->state != __IDPF_VPORT_UP ||
+ dont_wake = !test_bit(IDPF_VPORT_UP, np->state) ||
!netif_carrier_ok(tx_q->netdev);
__netif_txq_completed_wake(nq, ss.packets, ss.bytes,
IDPF_DESC_UNUSED(tx_q), IDPF_TX_WAKE_THRESH,
diff --git a/drivers/net/ethernet/intel/idpf/idpf_txrx.c b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
index eaad52a83b04..d6affa6535f7 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_txrx.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_txrx.c
@@ -1869,7 +1869,7 @@ static bool idpf_tx_clean_complq(struct idpf_compl_queue *complq, int budget,
/* Update BQL */
nq = netdev_get_tx_queue(tx_q->netdev, tx_q->idx);
- dont_wake = !complq_ok || np->state != __IDPF_VPORT_UP ||
+ dont_wake = !complq_ok || !test_bit(IDPF_VPORT_UP, np->state) ||
!netif_carrier_ok(tx_q->netdev);
/* Check if the TXQ needs to and can be restarted */
__netif_txq_completed_wake(nq, tx_q->cleaned_pkts, tx_q->cleaned_bytes,
diff --git a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
index c1f34381333d..e68572c602eb 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_virtchnl.c
@@ -68,7 +68,7 @@ static void idpf_handle_event_link(struct idpf_adapter *adapter,
vport->link_up = v2e->link_status;
- if (np->state != __IDPF_VPORT_UP)
+ if (!test_bit(IDPF_VPORT_UP, np->state))
return;
if (vport->link_up) {
@@ -2432,7 +2432,7 @@ int idpf_send_get_stats_msg(struct idpf_vport *vport)
/* Don't send get_stats message if the link is down */
- if (np->state <= __IDPF_VPORT_DOWN)
+ if (!test_bit(IDPF_VPORT_UP, np->state))
return 0;
stats_msg.vport_id = cpu_to_le32(vport->vport_id);
--
2.51.0.rc1.197.g6d975e95c9d7
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH net 3/8] idpf: fix possible race in idpf_vport_stop()
2025-10-02 0:14 [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf) Jacob Keller
2025-10-02 0:14 ` [PATCH net 1/8] idpf: cleanup remaining SKBs in PTP flows Jacob Keller
2025-10-02 0:14 ` [PATCH net 2/8] idpf: convert vport state to bitmap Jacob Keller
@ 2025-10-02 0:14 ` Jacob Keller
2025-10-03 17:43 ` Jakub Kicinski
2025-10-02 0:14 ` [PATCH net 4/8] ixgbevf: fix getting link speed data for E610 devices Jacob Keller
` (6 subsequent siblings)
9 siblings, 1 reply; 21+ messages in thread
From: Jacob Keller @ 2025-10-02 0:14 UTC (permalink / raw)
To: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Emil Tantilov, Pavan Kumar Linga,
Alexander Lobakin, Willem de Bruijn, Sridhar Samudrala,
Phani Burra, Piotr Kwapulinski, Simon Horman, Radoslaw Tyl,
Jedrzej Jagielski, Mateusz Polchlopek
Cc: Anton Nadezhdin, Konstantin Ilichev, Milena Olech, netdev,
linux-kernel, Jacob Keller, Joshua Hay, Aleksandr Loktionov,
Chittim Madhu, Samuel Salin
From: Emil Tantilov <emil.s.tantilov@intel.com>
Make sure to clear the IDPF_VPORT_UP bit on entry. The idpf_vport_stop()
function is void and once called, the vport teardown is guaranteed to
happen. Previously the bit was cleared at the end of the function, which
opened it up to possible races with all instances in the driver where
operations were conditional on this bit being set. For example, on rmmod
callbacks in the middle of idpf_vport_stop() end up attempting to remove
MAC address filter already removed by the function:
idpf 0000:83:00.0: Received invalid MAC filter payload (op 536) (len 0)
Fixes: 1c325aac10a8 ("idpf: configure resources for TX queues")
Reviewed-by: Joshua Hay <joshua.a.hay@intel.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Chittim Madhu <madhu.chittim@intel.com>
Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com>
Tested-by: Samuel Salin <Samuel.salin@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
---
drivers/net/ethernet/intel/idpf/idpf_lib.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/idpf/idpf_lib.c b/drivers/net/ethernet/intel/idpf/idpf_lib.c
index 89d30c395533..01ab42fa23f9 100644
--- a/drivers/net/ethernet/intel/idpf/idpf_lib.c
+++ b/drivers/net/ethernet/intel/idpf/idpf_lib.c
@@ -888,7 +888,7 @@ static void idpf_vport_stop(struct idpf_vport *vport)
{
struct idpf_netdev_priv *np = netdev_priv(vport->netdev);
- if (!test_bit(IDPF_VPORT_UP, np->state))
+ if (!test_and_clear_bit(IDPF_VPORT_UP, np->state))
return;
netif_carrier_off(vport->netdev);
@@ -911,7 +911,6 @@ static void idpf_vport_stop(struct idpf_vport *vport)
idpf_vport_intr_deinit(vport);
idpf_vport_queues_rel(vport);
idpf_vport_intr_rel(vport);
- clear_bit(IDPF_VPORT_UP, np->state);
}
/**
--
2.51.0.rc1.197.g6d975e95c9d7
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH net 4/8] ixgbevf: fix getting link speed data for E610 devices
2025-10-02 0:14 [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf) Jacob Keller
` (2 preceding siblings ...)
2025-10-02 0:14 ` [PATCH net 3/8] idpf: fix possible race in idpf_vport_stop() Jacob Keller
@ 2025-10-02 0:14 ` Jacob Keller
2025-10-02 0:14 ` [PATCH net 5/8] ixgbe: handle IXGBE_VF_GET_PF_LINK_STATE mailbox operation Jacob Keller
` (5 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: Jacob Keller @ 2025-10-02 0:14 UTC (permalink / raw)
To: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Emil Tantilov, Pavan Kumar Linga,
Alexander Lobakin, Willem de Bruijn, Sridhar Samudrala,
Phani Burra, Piotr Kwapulinski, Simon Horman, Radoslaw Tyl,
Jedrzej Jagielski, Mateusz Polchlopek
Cc: Anton Nadezhdin, Konstantin Ilichev, Milena Olech, netdev,
linux-kernel, Jacob Keller, Andrzej Wilczynski,
Aleksandr Loktionov, stable, Rafal Romanowski
From: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
E610 adapters no longer use the VFLINKS register to read PF's link
speed and linkup state. As a result VF driver cannot get actual link
state and it incorrectly reports 10G which is the default option.
It leads to a situation where even 1G adapters print 10G as actual
link speed. The same happens when PF driver set speed different than 10G.
Add new mailbox operation to let the VF driver request a PF driver
to provide actual link data. Update the mailbox api to v1.6.
Incorporate both ways of getting link status within the legacy
ixgbe_check_mac_link_vf() function.
Fixes: 4c44b450c69b ("ixgbevf: Add support for Intel(R) E610 device")
Co-developed-by: Andrzej Wilczynski <andrzejx.wilczynski@intel.com>
Signed-off-by: Andrzej Wilczynski <andrzejx.wilczynski@intel.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
---
drivers/net/ethernet/intel/ixgbevf/defines.h | 1 +
drivers/net/ethernet/intel/ixgbevf/mbx.h | 4 +
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 6 +-
drivers/net/ethernet/intel/ixgbevf/vf.c | 137 +++++++++++++++++-----
4 files changed, 116 insertions(+), 32 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/defines.h b/drivers/net/ethernet/intel/ixgbevf/defines.h
index a9bc96f6399d..e177d1d58696 100644
--- a/drivers/net/ethernet/intel/ixgbevf/defines.h
+++ b/drivers/net/ethernet/intel/ixgbevf/defines.h
@@ -28,6 +28,7 @@
/* Link speed */
typedef u32 ixgbe_link_speed;
+#define IXGBE_LINK_SPEED_UNKNOWN 0
#define IXGBE_LINK_SPEED_1GB_FULL 0x0020
#define IXGBE_LINK_SPEED_10GB_FULL 0x0080
#define IXGBE_LINK_SPEED_100_FULL 0x0008
diff --git a/drivers/net/ethernet/intel/ixgbevf/mbx.h b/drivers/net/ethernet/intel/ixgbevf/mbx.h
index 835bbcc5cc8e..c1494fd1f67b 100644
--- a/drivers/net/ethernet/intel/ixgbevf/mbx.h
+++ b/drivers/net/ethernet/intel/ixgbevf/mbx.h
@@ -66,6 +66,7 @@ enum ixgbe_pfvf_api_rev {
ixgbe_mbox_api_13, /* API version 1.3, linux/freebsd VF driver */
ixgbe_mbox_api_14, /* API version 1.4, linux/freebsd VF driver */
ixgbe_mbox_api_15, /* API version 1.5, linux/freebsd VF driver */
+ ixgbe_mbox_api_16, /* API version 1.6, linux/freebsd VF driver */
/* This value should always be last */
ixgbe_mbox_api_unknown, /* indicates that API version is not known */
};
@@ -102,6 +103,9 @@ enum ixgbe_pfvf_api_rev {
#define IXGBE_VF_GET_LINK_STATE 0x10 /* get vf link state */
+/* mailbox API, version 1.6 VF requests */
+#define IXGBE_VF_GET_PF_LINK_STATE 0x11 /* request PF to send link info */
+
/* length of permanent address message returned from PF */
#define IXGBE_VF_PERMADDR_MSG_LEN 4
/* word in permanent address message with the current multicast type */
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 535d0f71f521..574714764791 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -2275,6 +2275,7 @@ static void ixgbevf_negotiate_api(struct ixgbevf_adapter *adapter)
{
struct ixgbe_hw *hw = &adapter->hw;
static const int api[] = {
+ ixgbe_mbox_api_16,
ixgbe_mbox_api_15,
ixgbe_mbox_api_14,
ixgbe_mbox_api_13,
@@ -2294,7 +2295,8 @@ static void ixgbevf_negotiate_api(struct ixgbevf_adapter *adapter)
idx++;
}
- if (hw->api_version >= ixgbe_mbox_api_15) {
+ /* Following is not supported by API 1.6, it is specific for 1.5 */
+ if (hw->api_version == ixgbe_mbox_api_15) {
hw->mbx.ops.init_params(hw);
memcpy(&hw->mbx.ops, &ixgbevf_mbx_ops,
sizeof(struct ixgbe_mbx_operations));
@@ -2651,6 +2653,7 @@ static void ixgbevf_set_num_queues(struct ixgbevf_adapter *adapter)
case ixgbe_mbox_api_13:
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_15:
+ case ixgbe_mbox_api_16:
if (adapter->xdp_prog &&
hw->mac.max_tx_queues == rss)
rss = rss > 3 ? 2 : 1;
@@ -4645,6 +4648,7 @@ static int ixgbevf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
case ixgbe_mbox_api_13:
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_15:
+ case ixgbe_mbox_api_16:
netdev->max_mtu = IXGBE_MAX_JUMBO_FRAME_SIZE -
(ETH_HLEN + ETH_FCS_LEN);
break;
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c
index dcaef34b88b6..f05246fb5a74 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.c
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
@@ -313,6 +313,7 @@ int ixgbevf_get_reta_locked(struct ixgbe_hw *hw, u32 *reta, int num_rx_queues)
* is not supported for this device type.
*/
switch (hw->api_version) {
+ case ixgbe_mbox_api_16:
case ixgbe_mbox_api_15:
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_13:
@@ -382,6 +383,7 @@ int ixgbevf_get_rss_key_locked(struct ixgbe_hw *hw, u8 *rss_key)
* or if the operation is not supported for this device type.
*/
switch (hw->api_version) {
+ case ixgbe_mbox_api_16:
case ixgbe_mbox_api_15:
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_13:
@@ -552,6 +554,7 @@ static s32 ixgbevf_update_xcast_mode(struct ixgbe_hw *hw, int xcast_mode)
case ixgbe_mbox_api_13:
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_15:
+ case ixgbe_mbox_api_16:
break;
default:
return -EOPNOTSUPP;
@@ -624,6 +627,48 @@ static s32 ixgbevf_hv_get_link_state_vf(struct ixgbe_hw *hw, bool *link_state)
return -EOPNOTSUPP;
}
+/**
+ * ixgbevf_get_pf_link_state - Get PF's link status
+ * @hw: pointer to the HW structure
+ * @speed: link speed
+ * @link_up: indicate if link is up/down
+ *
+ * Ask PF to provide link_up state and speed of the link.
+ *
+ * Return: IXGBE_ERR_MBX in the case of mailbox error,
+ * -EOPNOTSUPP if the op is not supported or 0 on success.
+ */
+static int ixgbevf_get_pf_link_state(struct ixgbe_hw *hw, ixgbe_link_speed *speed,
+ bool *link_up)
+{
+ u32 msgbuf[3] = {};
+ int err;
+
+ switch (hw->api_version) {
+ case ixgbe_mbox_api_16:
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ msgbuf[0] = IXGBE_VF_GET_PF_LINK_STATE;
+
+ err = ixgbevf_write_msg_read_ack(hw, msgbuf, msgbuf,
+ ARRAY_SIZE(msgbuf));
+ if (err || (msgbuf[0] & IXGBE_VT_MSGTYPE_FAILURE)) {
+ err = IXGBE_ERR_MBX;
+ *speed = IXGBE_LINK_SPEED_UNKNOWN;
+ /* No need to set @link_up to false as it will be done by
+ * ixgbe_check_mac_link_vf().
+ */
+ } else {
+ *speed = msgbuf[1];
+ *link_up = msgbuf[2];
+ }
+
+ return err;
+}
+
/**
* ixgbevf_set_vfta_vf - Set/Unset VLAN filter table address
* @hw: pointer to the HW structure
@@ -658,6 +703,58 @@ static s32 ixgbevf_set_vfta_vf(struct ixgbe_hw *hw, u32 vlan, u32 vind,
return err;
}
+/**
+ * ixgbe_read_vflinks - Read VFLINKS register
+ * @hw: pointer to the HW structure
+ * @speed: link speed
+ * @link_up: indicate if link is up/down
+ *
+ * Get linkup status and link speed from the VFLINKS register.
+ */
+static void ixgbe_read_vflinks(struct ixgbe_hw *hw, ixgbe_link_speed *speed,
+ bool *link_up)
+{
+ u32 vflinks = IXGBE_READ_REG(hw, IXGBE_VFLINKS);
+
+ /* if link status is down no point in checking to see if PF is up */
+ if (!(vflinks & IXGBE_LINKS_UP)) {
+ *link_up = false;
+ return;
+ }
+
+ /* for SFP+ modules and DA cables on 82599 it can take up to 500usecs
+ * before the link status is correct
+ */
+ if (hw->mac.type == ixgbe_mac_82599_vf) {
+ for (int i = 0; i < 5; i++) {
+ udelay(100);
+ vflinks = IXGBE_READ_REG(hw, IXGBE_VFLINKS);
+
+ if (!(vflinks & IXGBE_LINKS_UP)) {
+ *link_up = false;
+ return;
+ }
+ }
+ }
+
+ /* We reached this point so there's link */
+ *link_up = true;
+
+ switch (vflinks & IXGBE_LINKS_SPEED_82599) {
+ case IXGBE_LINKS_SPEED_10G_82599:
+ *speed = IXGBE_LINK_SPEED_10GB_FULL;
+ break;
+ case IXGBE_LINKS_SPEED_1G_82599:
+ *speed = IXGBE_LINK_SPEED_1GB_FULL;
+ break;
+ case IXGBE_LINKS_SPEED_100_82599:
+ *speed = IXGBE_LINK_SPEED_100_FULL;
+ break;
+ default:
+ *speed = IXGBE_LINK_SPEED_UNKNOWN;
+ }
+}
+
/**
* ixgbevf_hv_set_vfta_vf - * Hyper-V variant - just a stub.
* @hw: unused
@@ -705,7 +802,6 @@ static s32 ixgbevf_check_mac_link_vf(struct ixgbe_hw *hw,
struct ixgbe_mbx_info *mbx = &hw->mbx;
struct ixgbe_mac_info *mac = &hw->mac;
s32 ret_val = 0;
- u32 links_reg;
u32 in_msg = 0;
/* If we were hit with a reset drop the link */
@@ -715,36 +811,14 @@ static s32 ixgbevf_check_mac_link_vf(struct ixgbe_hw *hw,
if (!mac->get_link_status)
goto out;
- /* if link status is down no point in checking to see if pf is up */
- links_reg = IXGBE_READ_REG(hw, IXGBE_VFLINKS);
- if (!(links_reg & IXGBE_LINKS_UP))
- goto out;
-
- /* for SFP+ modules and DA cables on 82599 it can take up to 500usecs
- * before the link status is correct
- */
- if (mac->type == ixgbe_mac_82599_vf) {
- int i;
-
- for (i = 0; i < 5; i++) {
- udelay(100);
- links_reg = IXGBE_READ_REG(hw, IXGBE_VFLINKS);
-
- if (!(links_reg & IXGBE_LINKS_UP))
- goto out;
- }
- }
-
- switch (links_reg & IXGBE_LINKS_SPEED_82599) {
- case IXGBE_LINKS_SPEED_10G_82599:
- *speed = IXGBE_LINK_SPEED_10GB_FULL;
- break;
- case IXGBE_LINKS_SPEED_1G_82599:
- *speed = IXGBE_LINK_SPEED_1GB_FULL;
- break;
- case IXGBE_LINKS_SPEED_100_82599:
- *speed = IXGBE_LINK_SPEED_100_FULL;
- break;
+ if (hw->mac.type == ixgbe_mac_e610_vf) {
+ ret_val = ixgbevf_get_pf_link_state(hw, speed, link_up);
+ if (ret_val)
+ goto out;
+ } else {
+ ixgbe_read_vflinks(hw, speed, link_up);
+ if (*link_up == false)
+ goto out;
}
/* if the read failed it could just be a mailbox collision, best wait
@@ -951,6 +1025,7 @@ int ixgbevf_get_queues(struct ixgbe_hw *hw, unsigned int *num_tcs,
case ixgbe_mbox_api_13:
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_15:
+ case ixgbe_mbox_api_16:
break;
default:
return 0;
--
2.51.0.rc1.197.g6d975e95c9d7
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH net 5/8] ixgbe: handle IXGBE_VF_GET_PF_LINK_STATE mailbox operation
2025-10-02 0:14 [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf) Jacob Keller
` (3 preceding siblings ...)
2025-10-02 0:14 ` [PATCH net 4/8] ixgbevf: fix getting link speed data for E610 devices Jacob Keller
@ 2025-10-02 0:14 ` Jacob Keller
2025-10-02 0:14 ` [PATCH net 6/8] ixgbevf: fix mailbox API compatibility by negotiating supported features Jacob Keller
` (4 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: Jacob Keller @ 2025-10-02 0:14 UTC (permalink / raw)
To: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Emil Tantilov, Pavan Kumar Linga,
Alexander Lobakin, Willem de Bruijn, Sridhar Samudrala,
Phani Burra, Piotr Kwapulinski, Simon Horman, Radoslaw Tyl,
Jedrzej Jagielski, Mateusz Polchlopek
Cc: Anton Nadezhdin, Konstantin Ilichev, Milena Olech, netdev,
linux-kernel, Jacob Keller, Aleksandr Loktionov, Rafal Romanowski
From: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
Update supported API version and provide handler for
IXGBE_VF_GET_PF_LINK_STATE cmd.
Simply put stored values of link speed and link_up from adapter context.
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
Link: https://lore.kernel.org/stable/20250828095227.1857066-3-jedrzej.jagielski%40intel.com
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 5 +++
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 42 ++++++++++++++++++++++++++
2 files changed, 47 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
index 4af149b63a39..f7256a339c99 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
@@ -50,6 +50,8 @@ enum ixgbe_pfvf_api_rev {
ixgbe_mbox_api_12, /* API version 1.2, linux/freebsd VF driver */
ixgbe_mbox_api_13, /* API version 1.3, linux/freebsd VF driver */
ixgbe_mbox_api_14, /* API version 1.4, linux/freebsd VF driver */
+ ixgbe_mbox_api_15, /* API version 1.5, linux/freebsd VF driver */
+ ixgbe_mbox_api_16, /* API version 1.6, linux/freebsd VF driver */
/* This value should always be last */
ixgbe_mbox_api_unknown, /* indicates that API version is not known */
};
@@ -86,6 +88,9 @@ enum ixgbe_pfvf_api_rev {
#define IXGBE_VF_GET_LINK_STATE 0x10 /* get vf link state */
+/* mailbox API, version 1.6 VF requests */
+#define IXGBE_VF_GET_PF_LINK_STATE 0x11 /* request PF to send link info */
+
/* length of permanent address message returned from PF */
#define IXGBE_VF_PERMADDR_MSG_LEN 4
/* word in permanent address message with the current multicast type */
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index 32ac1e020d91..b09271d61a4e 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -510,6 +510,7 @@ static int ixgbe_set_vf_lpe(struct ixgbe_adapter *adapter, u32 max_frame, u32 vf
case ixgbe_mbox_api_12:
case ixgbe_mbox_api_13:
case ixgbe_mbox_api_14:
+ case ixgbe_mbox_api_16:
/* Version 1.1 supports jumbo frames on VFs if PF has
* jumbo frames enabled which means legacy VFs are
* disabled
@@ -1046,6 +1047,7 @@ static int ixgbe_negotiate_vf_api(struct ixgbe_adapter *adapter,
case ixgbe_mbox_api_12:
case ixgbe_mbox_api_13:
case ixgbe_mbox_api_14:
+ case ixgbe_mbox_api_16:
adapter->vfinfo[vf].vf_api = api;
return 0;
default:
@@ -1072,6 +1074,7 @@ static int ixgbe_get_vf_queues(struct ixgbe_adapter *adapter,
case ixgbe_mbox_api_12:
case ixgbe_mbox_api_13:
case ixgbe_mbox_api_14:
+ case ixgbe_mbox_api_16:
break;
default:
return -1;
@@ -1112,6 +1115,7 @@ static int ixgbe_get_vf_reta(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
/* verify the PF is supporting the correct API */
switch (adapter->vfinfo[vf].vf_api) {
+ case ixgbe_mbox_api_16:
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_13:
case ixgbe_mbox_api_12:
@@ -1145,6 +1149,7 @@ static int ixgbe_get_vf_rss_key(struct ixgbe_adapter *adapter,
/* verify the PF is supporting the correct API */
switch (adapter->vfinfo[vf].vf_api) {
+ case ixgbe_mbox_api_16:
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_13:
case ixgbe_mbox_api_12:
@@ -1174,6 +1179,7 @@ static int ixgbe_update_vf_xcast_mode(struct ixgbe_adapter *adapter,
fallthrough;
case ixgbe_mbox_api_13:
case ixgbe_mbox_api_14:
+ case ixgbe_mbox_api_16:
break;
default:
return -EOPNOTSUPP;
@@ -1244,6 +1250,7 @@ static int ixgbe_get_vf_link_state(struct ixgbe_adapter *adapter,
case ixgbe_mbox_api_12:
case ixgbe_mbox_api_13:
case ixgbe_mbox_api_14:
+ case ixgbe_mbox_api_16:
break;
default:
return -EOPNOTSUPP;
@@ -1254,6 +1261,38 @@ static int ixgbe_get_vf_link_state(struct ixgbe_adapter *adapter,
return 0;
}
+/**
+ * ixgbe_send_vf_link_status - send link status data to VF
+ * @adapter: pointer to adapter struct
+ * @msgbuf: pointer to message buffers
+ * @vf: VF identifier
+ *
+ * Reply for IXGBE_VF_GET_PF_LINK_STATE mbox command sending link status data.
+ *
+ * Return: 0 on success or -EOPNOTSUPP when operation is not supported.
+ */
+static int ixgbe_send_vf_link_status(struct ixgbe_adapter *adapter,
+ u32 *msgbuf, u32 vf)
+{
+ struct ixgbe_hw *hw = &adapter->hw;
+
+ switch (adapter->vfinfo[vf].vf_api) {
+ case ixgbe_mbox_api_16:
+ if (hw->mac.type != ixgbe_mac_e610)
+ return -EOPNOTSUPP;
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+ /* Simply provide stored values as watchdog & link status events take
+ * care of its freshness.
+ */
+ msgbuf[1] = adapter->link_speed;
+ msgbuf[2] = adapter->link_up;
+
+ return 0;
+}
+
static int ixgbe_rcv_msg_from_vf(struct ixgbe_adapter *adapter, u32 vf)
{
u32 mbx_size = IXGBE_VFMAILBOX_SIZE;
@@ -1328,6 +1367,9 @@ static int ixgbe_rcv_msg_from_vf(struct ixgbe_adapter *adapter, u32 vf)
case IXGBE_VF_IPSEC_DEL:
retval = ixgbe_ipsec_vf_del_sa(adapter, msgbuf, vf);
break;
+ case IXGBE_VF_GET_PF_LINK_STATE:
+ retval = ixgbe_send_vf_link_status(adapter, msgbuf, vf);
+ break;
default:
e_err(drv, "Unhandled Msg %8.8x\n", msgbuf[0]);
retval = -EIO;
--
2.51.0.rc1.197.g6d975e95c9d7
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH net 6/8] ixgbevf: fix mailbox API compatibility by negotiating supported features
2025-10-02 0:14 [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf) Jacob Keller
` (4 preceding siblings ...)
2025-10-02 0:14 ` [PATCH net 5/8] ixgbe: handle IXGBE_VF_GET_PF_LINK_STATE mailbox operation Jacob Keller
@ 2025-10-02 0:14 ` Jacob Keller
2025-10-02 0:14 ` [PATCH net 7/8] ixgbe: handle IXGBE_VF_FEATURES_NEGOTIATE mbox cmd Jacob Keller
` (3 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: Jacob Keller @ 2025-10-02 0:14 UTC (permalink / raw)
To: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Emil Tantilov, Pavan Kumar Linga,
Alexander Lobakin, Willem de Bruijn, Sridhar Samudrala,
Phani Burra, Piotr Kwapulinski, Simon Horman, Radoslaw Tyl,
Jedrzej Jagielski, Mateusz Polchlopek
Cc: Anton Nadezhdin, Konstantin Ilichev, Milena Olech, netdev,
linux-kernel, Jacob Keller, Aleksandr Loktionov, stable,
Rafal Romanowski
From: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
There was backward compatibility in the terms of mailbox API. Various
drivers from various OSes supporting 10G adapters from Intel portfolio
could easily negotiate mailbox API.
This convention has been broken since introducing API 1.4.
Commit 0062e7cc955e ("ixgbevf: add VF IPsec offload code") added support
for IPSec which is specific only for the kernel ixgbe driver. None of the
rest of the Intel 10G PF/VF drivers supports it. And actually lack of
support was not included in the IPSec implementation - there were no such
code paths. No possibility to negotiate support for the feature was
introduced along with introduction of the feature itself.
Commit 339f28964147 ("ixgbevf: Add support for new mailbox communication
between PF and VF") increasing API version to 1.5 did the same - it
introduced code supported specifically by the PF ESX driver. It altered API
version for the VF driver in the same time not touching the version
defined for the PF ixgbe driver. It led to additional discrepancies,
as the code provided within API 1.6 cannot be supported for Linux ixgbe
driver as it causes crashes.
The issue was noticed some time ago and mitigated by Jake within the commit
d0725312adf5 ("ixgbevf: stop attempting IPSEC offload on Mailbox API 1.5").
As a result we have regression for IPsec support and after increasing API
to version 1.6 ixgbevf driver stopped to support ESX MBX.
To fix this mess add new mailbox op asking PF driver about supported
features. Basing on a response determine whether to set support for IPSec
and ESX-specific enhanced mailbox.
New mailbox op, for compatibility purposes, must be added within new API
revision, as API version of OOT PF & VF drivers is already increased to
1.6 and doesn't incorporate features negotiate op.
Features negotiation mechanism gives possibility to be extended with new
features when needed in the future.
Reported-by: Jacob Keller <jacob.e.keller@intel.com>
Closes: https://lore.kernel.org/intel-wired-lan/20241101-jk-ixgbevf-mailbox-v1-5-fixes-v1-0-f556dc9a66ed@intel.com/
Fixes: 0062e7cc955e ("ixgbevf: add VF IPsec offload code")
Fixes: 339f28964147 ("ixgbevf: Add support for new mailbox communication between PF and VF")
Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
---
drivers/net/ethernet/intel/ixgbevf/ixgbevf.h | 7 ++++
drivers/net/ethernet/intel/ixgbevf/mbx.h | 4 ++
drivers/net/ethernet/intel/ixgbevf/vf.h | 1 +
drivers/net/ethernet/intel/ixgbevf/ipsec.c | 10 +++++
drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 32 +++++++++++++++-
drivers/net/ethernet/intel/ixgbevf/vf.c | 45 ++++++++++++++++++++++-
6 files changed, 96 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
index 3a379e6a3a2a..039187607e98 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf.h
@@ -363,6 +363,13 @@ struct ixgbevf_adapter {
struct ixgbe_hw hw;
u16 msg_enable;
+ u32 pf_features;
+#define IXGBEVF_PF_SUP_IPSEC BIT(0)
+#define IXGBEVF_PF_SUP_ESX_MBX BIT(1)
+
+#define IXGBEVF_SUPPORTED_FEATURES (IXGBEVF_PF_SUP_IPSEC | \
+ IXGBEVF_PF_SUP_ESX_MBX)
+
struct ixgbevf_hw_stats stats;
unsigned long state;
diff --git a/drivers/net/ethernet/intel/ixgbevf/mbx.h b/drivers/net/ethernet/intel/ixgbevf/mbx.h
index c1494fd1f67b..a8ed23ee66aa 100644
--- a/drivers/net/ethernet/intel/ixgbevf/mbx.h
+++ b/drivers/net/ethernet/intel/ixgbevf/mbx.h
@@ -67,6 +67,7 @@ enum ixgbe_pfvf_api_rev {
ixgbe_mbox_api_14, /* API version 1.4, linux/freebsd VF driver */
ixgbe_mbox_api_15, /* API version 1.5, linux/freebsd VF driver */
ixgbe_mbox_api_16, /* API version 1.6, linux/freebsd VF driver */
+ ixgbe_mbox_api_17, /* API version 1.7, linux/freebsd VF driver */
/* This value should always be last */
ixgbe_mbox_api_unknown, /* indicates that API version is not known */
};
@@ -106,6 +107,9 @@ enum ixgbe_pfvf_api_rev {
/* mailbox API, version 1.6 VF requests */
#define IXGBE_VF_GET_PF_LINK_STATE 0x11 /* request PF to send link info */
+/* mailbox API, version 1.7 VF requests */
+#define IXGBE_VF_FEATURES_NEGOTIATE 0x12 /* get features supported by PF*/
+
/* length of permanent address message returned from PF */
#define IXGBE_VF_PERMADDR_MSG_LEN 4
/* word in permanent address message with the current multicast type */
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.h b/drivers/net/ethernet/intel/ixgbevf/vf.h
index 2d791bc26ae4..4f19b8900c29 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.h
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.h
@@ -26,6 +26,7 @@ struct ixgbe_mac_operations {
s32 (*stop_adapter)(struct ixgbe_hw *);
s32 (*get_bus_info)(struct ixgbe_hw *);
s32 (*negotiate_api_version)(struct ixgbe_hw *hw, int api);
+ int (*negotiate_features)(struct ixgbe_hw *hw, u32 *pf_features);
/* Link */
s32 (*setup_link)(struct ixgbe_hw *, ixgbe_link_speed, bool, bool);
diff --git a/drivers/net/ethernet/intel/ixgbevf/ipsec.c b/drivers/net/ethernet/intel/ixgbevf/ipsec.c
index 65580b9cb06f..fce35924ff8b 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ipsec.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ipsec.c
@@ -273,6 +273,9 @@ static int ixgbevf_ipsec_add_sa(struct net_device *dev,
adapter = netdev_priv(dev);
ipsec = adapter->ipsec;
+ if (!(adapter->pf_features & IXGBEVF_PF_SUP_IPSEC))
+ return -EOPNOTSUPP;
+
if (xs->id.proto != IPPROTO_ESP && xs->id.proto != IPPROTO_AH) {
NL_SET_ERR_MSG_MOD(extack, "Unsupported protocol for IPsec offload");
return -EINVAL;
@@ -405,6 +408,9 @@ static void ixgbevf_ipsec_del_sa(struct net_device *dev,
adapter = netdev_priv(dev);
ipsec = adapter->ipsec;
+ if (!(adapter->pf_features & IXGBEVF_PF_SUP_IPSEC))
+ return;
+
if (xs->xso.dir == XFRM_DEV_OFFLOAD_IN) {
sa_idx = xs->xso.offload_handle - IXGBE_IPSEC_BASE_RX_INDEX;
@@ -612,6 +618,10 @@ void ixgbevf_init_ipsec_offload(struct ixgbevf_adapter *adapter)
size_t size;
switch (adapter->hw.api_version) {
+ case ixgbe_mbox_api_17:
+ if (!(adapter->pf_features & IXGBEVF_PF_SUP_IPSEC))
+ return;
+ break;
case ixgbe_mbox_api_14:
break;
default:
diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
index 574714764791..1ecfbbb95210 100644
--- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
+++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c
@@ -2271,10 +2271,35 @@ static void ixgbevf_init_last_counter_stats(struct ixgbevf_adapter *adapter)
adapter->stats.base_vfmprc = adapter->stats.last_vfmprc;
}
+/**
+ * ixgbevf_set_features - Set features supported by PF
+ * @adapter: pointer to the adapter struct
+ *
+ * Negotiate with PF supported features and then set pf_features accordingly.
+ */
+static void ixgbevf_set_features(struct ixgbevf_adapter *adapter)
+{
+ u32 *pf_features = &adapter->pf_features;
+ struct ixgbe_hw *hw = &adapter->hw;
+ int err;
+
+ err = hw->mac.ops.negotiate_features(hw, pf_features);
+ if (err && err != -EOPNOTSUPP)
+ netdev_dbg(adapter->netdev,
+ "PF feature negotiation failed.\n");
+
+ /* Address also pre API 1.7 cases */
+ if (hw->api_version == ixgbe_mbox_api_14)
+ *pf_features |= IXGBEVF_PF_SUP_IPSEC;
+ else if (hw->api_version == ixgbe_mbox_api_15)
+ *pf_features |= IXGBEVF_PF_SUP_ESX_MBX;
+}
+
static void ixgbevf_negotiate_api(struct ixgbevf_adapter *adapter)
{
struct ixgbe_hw *hw = &adapter->hw;
static const int api[] = {
+ ixgbe_mbox_api_17,
ixgbe_mbox_api_16,
ixgbe_mbox_api_15,
ixgbe_mbox_api_14,
@@ -2295,8 +2320,9 @@ static void ixgbevf_negotiate_api(struct ixgbevf_adapter *adapter)
idx++;
}
- /* Following is not supported by API 1.6, it is specific for 1.5 */
- if (hw->api_version == ixgbe_mbox_api_15) {
+ ixgbevf_set_features(adapter);
+
+ if (adapter->pf_features & IXGBEVF_PF_SUP_ESX_MBX) {
hw->mbx.ops.init_params(hw);
memcpy(&hw->mbx.ops, &ixgbevf_mbx_ops,
sizeof(struct ixgbe_mbx_operations));
@@ -2654,6 +2680,7 @@ static void ixgbevf_set_num_queues(struct ixgbevf_adapter *adapter)
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_15:
case ixgbe_mbox_api_16:
+ case ixgbe_mbox_api_17:
if (adapter->xdp_prog &&
hw->mac.max_tx_queues == rss)
rss = rss > 3 ? 2 : 1;
@@ -4649,6 +4676,7 @@ static int ixgbevf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_15:
case ixgbe_mbox_api_16:
+ case ixgbe_mbox_api_17:
netdev->max_mtu = IXGBE_MAX_JUMBO_FRAME_SIZE -
(ETH_HLEN + ETH_FCS_LEN);
break;
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c
index f05246fb5a74..74d320879513 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.c
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
@@ -313,6 +313,7 @@ int ixgbevf_get_reta_locked(struct ixgbe_hw *hw, u32 *reta, int num_rx_queues)
* is not supported for this device type.
*/
switch (hw->api_version) {
+ case ixgbe_mbox_api_17:
case ixgbe_mbox_api_16:
case ixgbe_mbox_api_15:
case ixgbe_mbox_api_14:
@@ -383,6 +384,7 @@ int ixgbevf_get_rss_key_locked(struct ixgbe_hw *hw, u8 *rss_key)
* or if the operation is not supported for this device type.
*/
switch (hw->api_version) {
+ case ixgbe_mbox_api_17:
case ixgbe_mbox_api_16:
case ixgbe_mbox_api_15:
case ixgbe_mbox_api_14:
@@ -555,6 +557,7 @@ static s32 ixgbevf_update_xcast_mode(struct ixgbe_hw *hw, int xcast_mode)
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_15:
case ixgbe_mbox_api_16:
+ case ixgbe_mbox_api_17:
break;
default:
return -EOPNOTSUPP;
@@ -646,6 +649,7 @@ static int ixgbevf_get_pf_link_state(struct ixgbe_hw *hw, ixgbe_link_speed *spee
switch (hw->api_version) {
case ixgbe_mbox_api_16:
+ case ixgbe_mbox_api_17:
break;
default:
return -EOPNOTSUPP;
@@ -669,6 +673,42 @@ static int ixgbevf_get_pf_link_state(struct ixgbe_hw *hw, ixgbe_link_speed *spee
return err;
}
+/**
+ * ixgbevf_negotiate_features_vf - negotiate supported features with PF driver
+ * @hw: pointer to the HW structure
+ * @pf_features: bitmask of features supported by PF
+ *
+ * Return: IXGBE_ERR_MBX in the case of mailbox error,
+ * -EOPNOTSUPP if the op is not supported or 0 on success.
+ */
+static int ixgbevf_negotiate_features_vf(struct ixgbe_hw *hw, u32 *pf_features)
+{
+ u32 msgbuf[2] = {};
+ int err;
+
+ switch (hw->api_version) {
+ case ixgbe_mbox_api_17:
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ msgbuf[0] = IXGBE_VF_FEATURES_NEGOTIATE;
+ msgbuf[1] = IXGBEVF_SUPPORTED_FEATURES;
+
+ err = ixgbevf_write_msg_read_ack(hw, msgbuf, msgbuf,
+ ARRAY_SIZE(msgbuf));
+
+ if (err || (msgbuf[0] & IXGBE_VT_MSGTYPE_FAILURE)) {
+ err = IXGBE_ERR_MBX;
+ *pf_features = 0x0;
+ } else {
+ *pf_features = msgbuf[1];
+ }
+
+ return err;
+}
+
/**
* ixgbevf_set_vfta_vf - Set/Unset VLAN filter table address
* @hw: pointer to the HW structure
@@ -799,6 +839,7 @@ static s32 ixgbevf_check_mac_link_vf(struct ixgbe_hw *hw,
bool *link_up,
bool autoneg_wait_to_complete)
{
+ struct ixgbevf_adapter *adapter = hw->back;
struct ixgbe_mbx_info *mbx = &hw->mbx;
struct ixgbe_mac_info *mac = &hw->mac;
s32 ret_val = 0;
@@ -825,7 +866,7 @@ static s32 ixgbevf_check_mac_link_vf(struct ixgbe_hw *hw,
* until we are called again and don't report an error
*/
if (mbx->ops.read(hw, &in_msg, 1)) {
- if (hw->api_version >= ixgbe_mbox_api_15)
+ if (adapter->pf_features & IXGBEVF_PF_SUP_ESX_MBX)
mac->get_link_status = false;
goto out;
}
@@ -1026,6 +1067,7 @@ int ixgbevf_get_queues(struct ixgbe_hw *hw, unsigned int *num_tcs,
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_15:
case ixgbe_mbox_api_16:
+ case ixgbe_mbox_api_17:
break;
default:
return 0;
@@ -1080,6 +1122,7 @@ static const struct ixgbe_mac_operations ixgbevf_mac_ops = {
.setup_link = ixgbevf_setup_mac_link_vf,
.check_link = ixgbevf_check_mac_link_vf,
.negotiate_api_version = ixgbevf_negotiate_api_version_vf,
+ .negotiate_features = ixgbevf_negotiate_features_vf,
.set_rar = ixgbevf_set_rar_vf,
.update_mc_addr_list = ixgbevf_update_mc_addr_list_vf,
.update_xcast_mode = ixgbevf_update_xcast_mode,
--
2.51.0.rc1.197.g6d975e95c9d7
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH net 7/8] ixgbe: handle IXGBE_VF_FEATURES_NEGOTIATE mbox cmd
2025-10-02 0:14 [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf) Jacob Keller
` (5 preceding siblings ...)
2025-10-02 0:14 ` [PATCH net 6/8] ixgbevf: fix mailbox API compatibility by negotiating supported features Jacob Keller
@ 2025-10-02 0:14 ` Jacob Keller
2025-10-02 0:14 ` [PATCH net 8/8] ixgbe: fix too early devlink_free() in ixgbe_remove() Jacob Keller
` (2 subsequent siblings)
9 siblings, 0 replies; 21+ messages in thread
From: Jacob Keller @ 2025-10-02 0:14 UTC (permalink / raw)
To: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Emil Tantilov, Pavan Kumar Linga,
Alexander Lobakin, Willem de Bruijn, Sridhar Samudrala,
Phani Burra, Piotr Kwapulinski, Simon Horman, Radoslaw Tyl,
Jedrzej Jagielski, Mateusz Polchlopek
Cc: Anton Nadezhdin, Konstantin Ilichev, Milena Olech, netdev,
linux-kernel, Jacob Keller, Aleksandr Loktionov, Rafal Romanowski
From: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
Send to VF information about features supported by the PF driver.
Increase API version to 1.7.
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
Tested-by: Rafal Romanowski <rafal.romanowski@intel.com>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h | 10 +++++++
drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c | 37 ++++++++++++++++++++++++++
2 files changed, 47 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
index f7256a339c99..0334ed4b8fa3 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_mbx.h
@@ -52,6 +52,7 @@ enum ixgbe_pfvf_api_rev {
ixgbe_mbox_api_14, /* API version 1.4, linux/freebsd VF driver */
ixgbe_mbox_api_15, /* API version 1.5, linux/freebsd VF driver */
ixgbe_mbox_api_16, /* API version 1.6, linux/freebsd VF driver */
+ ixgbe_mbox_api_17, /* API version 1.7, linux/freebsd VF driver */
/* This value should always be last */
ixgbe_mbox_api_unknown, /* indicates that API version is not known */
};
@@ -91,6 +92,9 @@ enum ixgbe_pfvf_api_rev {
/* mailbox API, version 1.6 VF requests */
#define IXGBE_VF_GET_PF_LINK_STATE 0x11 /* request PF to send link info */
+/* mailbox API, version 1.7 VF requests */
+#define IXGBE_VF_FEATURES_NEGOTIATE 0x12 /* get features supported by PF */
+
/* length of permanent address message returned from PF */
#define IXGBE_VF_PERMADDR_MSG_LEN 4
/* word in permanent address message with the current multicast type */
@@ -101,6 +105,12 @@ enum ixgbe_pfvf_api_rev {
#define IXGBE_VF_MBX_INIT_TIMEOUT 2000 /* number of retries on mailbox */
#define IXGBE_VF_MBX_INIT_DELAY 500 /* microseconds between retries */
+/* features negotiated between PF/VF */
+#define IXGBEVF_PF_SUP_IPSEC BIT(0)
+#define IXGBEVF_PF_SUP_ESX_MBX BIT(1)
+
+#define IXGBE_SUPPORTED_FEATURES IXGBEVF_PF_SUP_IPSEC
+
struct ixgbe_hw;
int ixgbe_read_mbx(struct ixgbe_hw *, u32 *, u16, u16);
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
index b09271d61a4e..ee133d6749b3 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_sriov.c
@@ -511,6 +511,7 @@ static int ixgbe_set_vf_lpe(struct ixgbe_adapter *adapter, u32 max_frame, u32 vf
case ixgbe_mbox_api_13:
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_16:
+ case ixgbe_mbox_api_17:
/* Version 1.1 supports jumbo frames on VFs if PF has
* jumbo frames enabled which means legacy VFs are
* disabled
@@ -1048,6 +1049,7 @@ static int ixgbe_negotiate_vf_api(struct ixgbe_adapter *adapter,
case ixgbe_mbox_api_13:
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_16:
+ case ixgbe_mbox_api_17:
adapter->vfinfo[vf].vf_api = api;
return 0;
default:
@@ -1075,6 +1077,7 @@ static int ixgbe_get_vf_queues(struct ixgbe_adapter *adapter,
case ixgbe_mbox_api_13:
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_16:
+ case ixgbe_mbox_api_17:
break;
default:
return -1;
@@ -1115,6 +1118,7 @@ static int ixgbe_get_vf_reta(struct ixgbe_adapter *adapter, u32 *msgbuf, u32 vf)
/* verify the PF is supporting the correct API */
switch (adapter->vfinfo[vf].vf_api) {
+ case ixgbe_mbox_api_17:
case ixgbe_mbox_api_16:
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_13:
@@ -1149,6 +1153,7 @@ static int ixgbe_get_vf_rss_key(struct ixgbe_adapter *adapter,
/* verify the PF is supporting the correct API */
switch (adapter->vfinfo[vf].vf_api) {
+ case ixgbe_mbox_api_17:
case ixgbe_mbox_api_16:
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_13:
@@ -1180,6 +1185,7 @@ static int ixgbe_update_vf_xcast_mode(struct ixgbe_adapter *adapter,
case ixgbe_mbox_api_13:
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_16:
+ case ixgbe_mbox_api_17:
break;
default:
return -EOPNOTSUPP;
@@ -1251,6 +1257,7 @@ static int ixgbe_get_vf_link_state(struct ixgbe_adapter *adapter,
case ixgbe_mbox_api_13:
case ixgbe_mbox_api_14:
case ixgbe_mbox_api_16:
+ case ixgbe_mbox_api_17:
break;
default:
return -EOPNOTSUPP;
@@ -1278,6 +1285,7 @@ static int ixgbe_send_vf_link_status(struct ixgbe_adapter *adapter,
switch (adapter->vfinfo[vf].vf_api) {
case ixgbe_mbox_api_16:
+ case ixgbe_mbox_api_17:
if (hw->mac.type != ixgbe_mac_e610)
return -EOPNOTSUPP;
break;
@@ -1293,6 +1301,32 @@ static int ixgbe_send_vf_link_status(struct ixgbe_adapter *adapter,
return 0;
}
+/**
+ * ixgbe_negotiate_vf_features - negotiate supported features with VF driver
+ * @adapter: pointer to adapter struct
+ * @msgbuf: pointer to message buffers
+ * @vf: VF identifier
+ *
+ * Return: 0 on success or -EOPNOTSUPP when operation is not supported.
+ */
+static int ixgbe_negotiate_vf_features(struct ixgbe_adapter *adapter,
+ u32 *msgbuf, u32 vf)
+{
+ u32 features = msgbuf[1];
+
+ switch (adapter->vfinfo[vf].vf_api) {
+ case ixgbe_mbox_api_17:
+ break;
+ default:
+ return -EOPNOTSUPP;
+ }
+
+ features &= IXGBE_SUPPORTED_FEATURES;
+ msgbuf[1] = features;
+
+ return 0;
+}
+
static int ixgbe_rcv_msg_from_vf(struct ixgbe_adapter *adapter, u32 vf)
{
u32 mbx_size = IXGBE_VFMAILBOX_SIZE;
@@ -1370,6 +1404,9 @@ static int ixgbe_rcv_msg_from_vf(struct ixgbe_adapter *adapter, u32 vf)
case IXGBE_VF_GET_PF_LINK_STATE:
retval = ixgbe_send_vf_link_status(adapter, msgbuf, vf);
break;
+ case IXGBE_VF_FEATURES_NEGOTIATE:
+ retval = ixgbe_negotiate_vf_features(adapter, msgbuf, vf);
+ break;
default:
e_err(drv, "Unhandled Msg %8.8x\n", msgbuf[0]);
retval = -EIO;
--
2.51.0.rc1.197.g6d975e95c9d7
^ permalink raw reply related [flat|nested] 21+ messages in thread
* [PATCH net 8/8] ixgbe: fix too early devlink_free() in ixgbe_remove()
2025-10-02 0:14 [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf) Jacob Keller
` (6 preceding siblings ...)
2025-10-02 0:14 ` [PATCH net 7/8] ixgbe: handle IXGBE_VF_FEATURES_NEGOTIATE mbox cmd Jacob Keller
@ 2025-10-02 0:14 ` Jacob Keller
2025-10-03 17:42 ` [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf) Jakub Kicinski
2025-10-06 15:27 ` Alexander Lobakin
9 siblings, 0 replies; 21+ messages in thread
From: Jacob Keller @ 2025-10-02 0:14 UTC (permalink / raw)
To: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Emil Tantilov, Pavan Kumar Linga,
Alexander Lobakin, Willem de Bruijn, Sridhar Samudrala,
Phani Burra, Piotr Kwapulinski, Simon Horman, Radoslaw Tyl,
Jedrzej Jagielski, Mateusz Polchlopek
Cc: Anton Nadezhdin, Konstantin Ilichev, Milena Olech, netdev,
linux-kernel, Jacob Keller, Koichiro Den, Rinitha S,
Aleksandr Loktionov, Paul Menzel
From: Koichiro Den <den@valinux.co.jp>
Since ixgbe_adapter is embedded in devlink, calling devlink_free()
prematurely in the ixgbe_remove() path can lead to UAF. Move devlink_free()
to the end.
KASAN report:
BUG: KASAN: use-after-free in ixgbe_reset_interrupt_capability+0x140/0x180 [ixgbe]
Read of size 8 at addr ffff0000adf813e0 by task bash/2095
CPU: 1 UID: 0 PID: 2095 Comm: bash Tainted: G S 6.17.0-rc2-tnguy.net-queue+ #1 PREEMPT(full)
[...]
Call trace:
show_stack+0x30/0x90 (C)
dump_stack_lvl+0x9c/0xd0
print_address_description.constprop.0+0x90/0x310
print_report+0x104/0x1f0
kasan_report+0x88/0x180
__asan_report_load8_noabort+0x20/0x30
ixgbe_reset_interrupt_capability+0x140/0x180 [ixgbe]
ixgbe_clear_interrupt_scheme+0xf8/0x130 [ixgbe]
ixgbe_remove+0x2d0/0x8c0 [ixgbe]
pci_device_remove+0xa0/0x220
device_remove+0xb8/0x170
device_release_driver_internal+0x318/0x490
device_driver_detach+0x40/0x68
unbind_store+0xec/0x118
drv_attr_store+0x64/0xb8
sysfs_kf_write+0xcc/0x138
kernfs_fop_write_iter+0x294/0x440
new_sync_write+0x1fc/0x588
vfs_write+0x480/0x6a0
ksys_write+0xf0/0x1e0
__arm64_sys_write+0x70/0xc0
invoke_syscall.constprop.0+0xcc/0x280
el0_svc_common.constprop.0+0xa8/0x248
do_el0_svc+0x44/0x68
el0_svc+0x54/0x160
el0t_64_sync_handler+0xa0/0xe8
el0t_64_sync+0x1b0/0x1b8
Fixes: a0285236ab93 ("ixgbe: add initial devlink support")
Signed-off-by: Koichiro Den <den@valinux.co.jp>
Tested-by: Rinitha S <sx.rinitha@intel.com>
Reviewed-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Paul Menzel <pmenzel@molgen.mpg.de>
---
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 6218bdb7f941..86b9caece104 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -12091,7 +12091,6 @@ static void ixgbe_remove(struct pci_dev *pdev)
devl_port_unregister(&adapter->devlink_port);
devl_unlock(adapter->devlink);
- devlink_free(adapter->devlink);
ixgbe_stop_ipsec_offload(adapter);
ixgbe_clear_interrupt_scheme(adapter);
@@ -12127,6 +12126,8 @@ static void ixgbe_remove(struct pci_dev *pdev)
if (disable_dev)
pci_disable_device(pdev);
+
+ devlink_free(adapter->devlink);
}
/**
--
2.51.0.rc1.197.g6d975e95c9d7
^ permalink raw reply related [flat|nested] 21+ messages in thread
* Re: [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf)
2025-10-02 0:14 [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf) Jacob Keller
` (7 preceding siblings ...)
2025-10-02 0:14 ` [PATCH net 8/8] ixgbe: fix too early devlink_free() in ixgbe_remove() Jacob Keller
@ 2025-10-03 17:42 ` Jakub Kicinski
2025-10-04 0:58 ` Jacob Keller
2025-10-06 15:27 ` Alexander Lobakin
9 siblings, 1 reply; 21+ messages in thread
From: Jakub Kicinski @ 2025-10-03 17:42 UTC (permalink / raw)
To: Jacob Keller
Cc: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Emil Tantilov, Pavan Kumar Linga, Alexander Lobakin,
Willem de Bruijn, Sridhar Samudrala, Phani Burra,
Piotr Kwapulinski, Simon Horman, Radoslaw Tyl, Jedrzej Jagielski,
Mateusz Polchlopek, Anton Nadezhdin, Konstantin Ilichev,
Milena Olech, netdev, linux-kernel, Aleksandr Loktionov,
Samuel Salin, Chittim Madhu, Joshua Hay, Andrzej Wilczynski,
stable, Rafal Romanowski, Koichiro Den, Rinitha S, Paul Menzel
On Wed, 01 Oct 2025 17:14:10 -0700 Jacob Keller wrote:
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
We need your sign-off on the patches.
Sorry for not noticing earlier.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH net 3/8] idpf: fix possible race in idpf_vport_stop()
2025-10-02 0:14 ` [PATCH net 3/8] idpf: fix possible race in idpf_vport_stop() Jacob Keller
@ 2025-10-03 17:43 ` Jakub Kicinski
2025-10-06 14:49 ` Tantilov, Emil S
0 siblings, 1 reply; 21+ messages in thread
From: Jakub Kicinski @ 2025-10-03 17:43 UTC (permalink / raw)
To: Jacob Keller
Cc: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Emil Tantilov, Pavan Kumar Linga, Alexander Lobakin,
Willem de Bruijn, Sridhar Samudrala, Phani Burra,
Piotr Kwapulinski, Simon Horman, Radoslaw Tyl, Jedrzej Jagielski,
Mateusz Polchlopek, Anton Nadezhdin, Konstantin Ilichev,
Milena Olech, netdev, linux-kernel, Joshua Hay,
Aleksandr Loktionov, Chittim Madhu, Samuel Salin
On Wed, 01 Oct 2025 17:14:13 -0700 Jacob Keller wrote:
> From: Emil Tantilov <emil.s.tantilov@intel.com>
>
> Make sure to clear the IDPF_VPORT_UP bit on entry. The idpf_vport_stop()
> function is void and once called, the vport teardown is guaranteed to
> happen. Previously the bit was cleared at the end of the function, which
> opened it up to possible races with all instances in the driver where
> operations were conditional on this bit being set. For example, on rmmod
> callbacks in the middle of idpf_vport_stop() end up attempting to remove
> MAC address filter already removed by the function:
> idpf 0000:83:00.0: Received invalid MAC filter payload (op 536) (len 0)
Argh, please stop using the flag based state machines. They CANNOT
replace locking. If there was proper locking in place it wouldn't
have mattered when we clear the flag.
I'm guessing false negatives are okay in how you use the UP flag?
The commit message doesn't really explain why.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf)
2025-10-03 17:42 ` [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf) Jakub Kicinski
@ 2025-10-04 0:58 ` Jacob Keller
0 siblings, 0 replies; 21+ messages in thread
From: Jacob Keller @ 2025-10-04 0:58 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Emil Tantilov, Pavan Kumar Linga, Alexander Lobakin,
Willem de Bruijn, Sridhar Samudrala, Phani Burra,
Piotr Kwapulinski, Simon Horman, Radoslaw Tyl, Jedrzej Jagielski,
Mateusz Polchlopek, Anton Nadezhdin, Konstantin Ilichev,
Milena Olech, netdev, linux-kernel, Aleksandr Loktionov,
Samuel Salin, Chittim Madhu, Joshua Hay, Andrzej Wilczynski,
stable, Rafal Romanowski, Koichiro Den, Rinitha S, Paul Menzel
[-- Attachment #1.1: Type: text/plain, Size: 362 bytes --]
On 10/3/2025 10:42 AM, Jakub Kicinski wrote:
> On Wed, 01 Oct 2025 17:14:10 -0700 Jacob Keller wrote:
>> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>
>
> We need your sign-off on the patches.
> Sorry for not noticing earlier.
Argh. Apologies for missing that. I'll resend the ones besides the idpf
fix you commented on.
Thanks,
Jake
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH net 3/8] idpf: fix possible race in idpf_vport_stop()
2025-10-03 17:43 ` Jakub Kicinski
@ 2025-10-06 14:49 ` Tantilov, Emil S
2025-10-06 17:26 ` Jakub Kicinski
0 siblings, 1 reply; 21+ messages in thread
From: Tantilov, Emil S @ 2025-10-06 14:49 UTC (permalink / raw)
To: Jakub Kicinski, Jacob Keller
Cc: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Pavan Kumar Linga, Alexander Lobakin,
Willem de Bruijn, Sridhar Samudrala, Phani Burra,
Piotr Kwapulinski, Simon Horman, Radoslaw Tyl, Jedrzej Jagielski,
Mateusz Polchlopek, Anton Nadezhdin, Konstantin Ilichev,
Milena Olech, netdev, linux-kernel, Joshua Hay,
Aleksandr Loktionov, Chittim Madhu, Samuel Salin
On 10/3/2025 10:43 AM, Jakub Kicinski wrote:
> On Wed, 01 Oct 2025 17:14:13 -0700 Jacob Keller wrote:
>> From: Emil Tantilov <emil.s.tantilov@intel.com>
>>
>> Make sure to clear the IDPF_VPORT_UP bit on entry. The idpf_vport_stop()
>> function is void and once called, the vport teardown is guaranteed to
>> happen. Previously the bit was cleared at the end of the function, which
>> opened it up to possible races with all instances in the driver where
>> operations were conditional on this bit being set. For example, on rmmod
>> callbacks in the middle of idpf_vport_stop() end up attempting to remove
>> MAC address filter already removed by the function:
>> idpf 0000:83:00.0: Received invalid MAC filter payload (op 536) (len 0)
>
> Argh, please stop using the flag based state machines. They CANNOT
> replace locking. If there was proper locking in place it wouldn't
> have mattered when we clear the flag.
This patch is resolving a bug in the current logic of how the flag is
used (not being atomic and not being cleared properly). I don't think
there is an existing lock in place to address this issue, though we are
looking to refactor the code over time to remove and/or limit how these
flags are used.
>
> I'm guessing false negatives are okay in how you use the UP flag?
> The commit message doesn't really explain why.
I am not sure I understand the question completely, if you mean that the
flag is cleared before the vport is actually brought down, I did touch
on it at the beginning of the description, once we enter
idpf_vport_stop() we know for sure that the vport will be brought down
and that is how the present checks in the driver for the UP flag are
being used. Specifically in the scenario that exposed this issue, the
driver will send a message in the middle of idpf_vport_down() after
checking the flag.
Thanks,
Emil
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf)
2025-10-02 0:14 [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf) Jacob Keller
` (8 preceding siblings ...)
2025-10-03 17:42 ` [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf) Jakub Kicinski
@ 2025-10-06 15:27 ` Alexander Lobakin
2025-10-06 21:59 ` Jacob Keller
2025-10-06 23:58 ` Jacob Keller
9 siblings, 2 replies; 21+ messages in thread
From: Alexander Lobakin @ 2025-10-06 15:27 UTC (permalink / raw)
To: Jacob Keller
Cc: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Emil Tantilov, Pavan Kumar Linga,
Willem de Bruijn, Sridhar Samudrala, Phani Burra,
Piotr Kwapulinski, Simon Horman, Radoslaw Tyl, Jedrzej Jagielski,
Mateusz Polchlopek, Anton Nadezhdin, Konstantin Ilichev,
Milena Olech, netdev, linux-kernel, Aleksandr Loktionov,
Samuel Salin, Chittim Madhu, Joshua Hay, Andrzej Wilczynski,
stable, Rafal Romanowski, Koichiro Den, Rinitha S, Paul Menzel
From: Jacob Keller <jacob.e.keller@intel.com>
Date: Wed, 01 Oct 2025 17:14:10 -0700
> For idpf:
> Milena fixes a memory leak in the idpf reset logic when the driver resets
> with an outstanding Tx timestamp.
>
> Emil fixes a race condition in idpf_vport_stop() by using
> test_and_clear_bit() to ensure we execute idpf_vport_stop() once.
Patches 2-3 (at least) triggered a good bunch of compiler errors in
Tony's queue due to that XDP and XSk support for idpf went into net-next
already, but these patches weren't rebased and retested after that.
Thanks,
Olek
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH net 3/8] idpf: fix possible race in idpf_vport_stop()
2025-10-06 14:49 ` Tantilov, Emil S
@ 2025-10-06 17:26 ` Jakub Kicinski
2025-10-07 0:07 ` Tantilov, Emil S
0 siblings, 1 reply; 21+ messages in thread
From: Jakub Kicinski @ 2025-10-06 17:26 UTC (permalink / raw)
To: Tantilov, Emil S
Cc: Jacob Keller, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, Pavan Kumar Linga, Alexander Lobakin,
Willem de Bruijn, Sridhar Samudrala, Phani Burra,
Piotr Kwapulinski, Simon Horman, Radoslaw Tyl, Jedrzej Jagielski,
Mateusz Polchlopek, Anton Nadezhdin, Konstantin Ilichev,
Milena Olech, netdev, linux-kernel, Joshua Hay,
Aleksandr Loktionov, Chittim Madhu, Samuel Salin
On Mon, 6 Oct 2025 07:49:32 -0700 Tantilov, Emil S wrote:
> > Argh, please stop using the flag based state machines. They CANNOT
> > replace locking. If there was proper locking in place it wouldn't
> > have mattered when we clear the flag.
>
> This patch is resolving a bug in the current logic of how the flag is
> used (not being atomic and not being cleared properly). I don't think
> there is an existing lock in place to address this issue, though we are
> looking to refactor the code over time to remove and/or limit how these
> flags are used.
Can you share more details about the race? If there is no lock in place
there's always the risk that:
CPU 0 CPU 1
idpf_vport_stop() whatever()
if (test_bit(UP))
# sees true
# !< long IRQ arrives
test_and_clear(UP)
...
all the rest
...
# > long IRQ ends
proceed but UP isn't really set any more
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf)
2025-10-06 15:27 ` Alexander Lobakin
@ 2025-10-06 21:59 ` Jacob Keller
2025-10-06 23:58 ` Jacob Keller
1 sibling, 0 replies; 21+ messages in thread
From: Jacob Keller @ 2025-10-06 21:59 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Emil Tantilov, Pavan Kumar Linga,
Willem de Bruijn, Sridhar Samudrala, Phani Burra,
Piotr Kwapulinski, Simon Horman, Radoslaw Tyl, Jedrzej Jagielski,
Mateusz Polchlopek, Anton Nadezhdin, Konstantin Ilichev,
Milena Olech, netdev, linux-kernel, Aleksandr Loktionov,
Samuel Salin, Chittim Madhu, Joshua Hay, Andrzej Wilczynski,
stable, Rafal Romanowski, Koichiro Den, Rinitha S, Paul Menzel
[-- Attachment #1.1: Type: text/plain, Size: 910 bytes --]
On 10/6/2025 8:27 AM, Alexander Lobakin wrote:
> From: Jacob Keller <jacob.e.keller@intel.com>
> Date: Wed, 01 Oct 2025 17:14:10 -0700
>
>> For idpf:
>> Milena fixes a memory leak in the idpf reset logic when the driver resets
>> with an outstanding Tx timestamp.
>>
>> Emil fixes a race condition in idpf_vport_stop() by using
>> test_and_clear_bit() to ensure we execute idpf_vport_stop() once.
> Patches 2-3 (at least) triggered a good bunch of compiler errors in
> Tony's queue due to that XDP and XSk support for idpf went into net-next
> already, but these patches weren't rebased and retested after that.
>
> Thanks,
> Olek
Yep, I thought I had based on this after the merge with the XDP support,
but apparently I was too early.
We have outstanding comments from Jakub on the flags changes, so I
dropped them from v2, but still have conflicts. Working on a v3 to fix that.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf)
2025-10-06 15:27 ` Alexander Lobakin
2025-10-06 21:59 ` Jacob Keller
@ 2025-10-06 23:58 ` Jacob Keller
1 sibling, 0 replies; 21+ messages in thread
From: Jacob Keller @ 2025-10-06 23:58 UTC (permalink / raw)
To: Alexander Lobakin
Cc: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Emil Tantilov, Willem de Bruijn,
Sridhar Samudrala, Phani Burra, Piotr Kwapulinski, Simon Horman,
Radoslaw Tyl, Jedrzej Jagielski, Mateusz Polchlopek,
Anton Nadezhdin, Konstantin Ilichev, Milena Olech, netdev,
linux-kernel, Aleksandr Loktionov, Samuel Salin, Chittim Madhu,
Joshua Hay, stable, Rafal Romanowski, Koichiro Den, Rinitha S,
Paul Menzel
[-- Attachment #1.1: Type: text/plain, Size: 787 bytes --]
On 10/6/2025 8:27 AM, Alexander Lobakin wrote:
> From: Jacob Keller <jacob.e.keller@intel.com>
> Date: Wed, 01 Oct 2025 17:14:10 -0700
>
>> For idpf:
>> Milena fixes a memory leak in the idpf reset logic when the driver resets
>> with an outstanding Tx timestamp.
>>
>> Emil fixes a race condition in idpf_vport_stop() by using
>> test_and_clear_bit() to ensure we execute idpf_vport_stop() once.
> Patches 2-3 (at least) triggered a good bunch of compiler errors in
> Tony's queue due to that XDP and XSk support for idpf went into net-next
> already, but these patches weren't rebased and retested after that.
>
> Thanks,
> Olek
I've at least fixed the compile failures on whats published in Tony's
dev-queue for net and next now. Thanks for letting me know.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH net 3/8] idpf: fix possible race in idpf_vport_stop()
2025-10-06 17:26 ` Jakub Kicinski
@ 2025-10-07 0:07 ` Tantilov, Emil S
2025-10-08 21:41 ` Jacob Keller
0 siblings, 1 reply; 21+ messages in thread
From: Tantilov, Emil S @ 2025-10-07 0:07 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Jacob Keller, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, Pavan Kumar Linga, Alexander Lobakin,
Willem de Bruijn, Sridhar Samudrala, Phani Burra,
Piotr Kwapulinski, Simon Horman, Radoslaw Tyl, Jedrzej Jagielski,
Mateusz Polchlopek, Anton Nadezhdin, Konstantin Ilichev,
Milena Olech, netdev, linux-kernel, Joshua Hay,
Aleksandr Loktionov, Chittim Madhu, Samuel Salin
On 10/6/2025 10:26 AM, Jakub Kicinski wrote:
> On Mon, 6 Oct 2025 07:49:32 -0700 Tantilov, Emil S wrote:
>>> Argh, please stop using the flag based state machines. They CANNOT
>>> replace locking. If there was proper locking in place it wouldn't
>>> have mattered when we clear the flag.
>>
>> This patch is resolving a bug in the current logic of how the flag is
>> used (not being atomic and not being cleared properly). I don't think
>> there is an existing lock in place to address this issue, though we are
>> looking to refactor the code over time to remove and/or limit how these
>> flags are used.
>
> Can you share more details about the race? If there is no lock in place
> there's always the risk that:
>
> CPU 0 CPU 1
> idpf_vport_stop() whatever()
> if (test_bit(UP))
> # sees true
> # !< long IRQ arrives
> test_and_clear(UP)
> ...
> all the rest
> ...
> # > long IRQ ends
> proceed but UP isn't really set any more
>
The specific case I was targeting with this patch is for when both
idpf_vport_stop() and idpf_addr_unsync(), called via set_rx_mode attempt
to delete the MAC filters. At least in my testing I have not seen a case
where the set_rx_mode callback will happen before idpf_vport_stop(). I
am assuming due to userspace reacting to the removal of the netdevs.
rmmod-6089 [021] ..... 3521.291596: idpf_remove
<-pci_device_remove
rmmod-6089 [021] ..... 3521.292686: idpf_vport_stop
<-idpf_vport_dealloc
systemd-resolve-1633 [022] b..1. 3521.295320: idpf_set_rx_mode
<-dev_mc_del
systemd-resolve-1633 [022] b..1. 3521.295338: idpf_addr_unsync
<-__hw_addr_sync_dev
systemd-resolve-1633 [022] b..1. 3521.295339: idpf_del_mac_filter
<-idpf_addr_unsync
systemd-resolve-1633 [022] b..1. 3521.295450: idpf_set_rx_mode
<-dev_mc_del
systemd-resolve-1633 [022] b..1. 3521.295451: idpf_addr_unsync
<-__hw_addr_sync_dev
systemd-resolve-1633 [022] b..1. 3521.295451: idpf_del_mac_filter
<-idpf_addr_unsync
rmmod-6089 [002] ..... 3521.934980: idpf_vport_stop
<-idpf_vport_dealloc
systemd-resolve-1633 [022] b..1. 3522.297299: idpf_set_rx_mode
<-dev_mc_del
systemd-resolve-1633 [022] b..1. 3522.297316: idpf_addr_unsync
<-__hw_addr_sync_dev
systemd-resolve-1633 [022] b..1. 3522.297317: idpf_del_mac_filter
<-idpf_addr_unsync
kworker/u261:2-3157 [037] ...1. 3522.297931:
idpf_mac_filter_async_handler: Received invalid MAC filter payload (op
536) (len 0)
rmmod-6089 [020] ..... 3522.573251: idpf_vport_stop
<-idpf_vport_dealloc
rmmod-6089 [002] ..... 3523.229936: idpf_vport_stop
<-idpf_vport_dealloc
systemd-resolve-1633 [022] b..1. 3523.311435: idpf_set_rx_mode
<-dev_mc_del
systemd-resolve-1633 [022] b..1. 3523.311452: idpf_addr_unsync
<-__hw_addr_sync_dev
systemd-resolve-1633 [022] b..1. 3523.311453: idpf_del_mac_filter
<-idpf_addr_unsync
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH net 3/8] idpf: fix possible race in idpf_vport_stop()
2025-10-07 0:07 ` Tantilov, Emil S
@ 2025-10-08 21:41 ` Jacob Keller
2025-10-13 18:13 ` Jakub Kicinski
0 siblings, 1 reply; 21+ messages in thread
From: Jacob Keller @ 2025-10-08 21:41 UTC (permalink / raw)
To: Tantilov, Emil S, Jakub Kicinski
Cc: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Pavan Kumar Linga, Alexander Lobakin,
Willem de Bruijn, Sridhar Samudrala, Phani Burra,
Piotr Kwapulinski, Simon Horman, Radoslaw Tyl, Jedrzej Jagielski,
Mateusz Polchlopek, Anton Nadezhdin, Konstantin Ilichev,
Milena Olech, netdev, linux-kernel, Joshua Hay,
Aleksandr Loktionov, Chittim Madhu, Samuel Salin
[-- Attachment #1.1: Type: text/plain, Size: 3672 bytes --]
On 10/6/2025 5:07 PM, Tantilov, Emil S wrote:
>
>
> On 10/6/2025 10:26 AM, Jakub Kicinski wrote:
>> On Mon, 6 Oct 2025 07:49:32 -0700 Tantilov, Emil S wrote:
>>>> Argh, please stop using the flag based state machines. They CANNOT
>>>> replace locking. If there was proper locking in place it wouldn't
>>>> have mattered when we clear the flag.
>>>
>>> This patch is resolving a bug in the current logic of how the flag is
>>> used (not being atomic and not being cleared properly). I don't think
>>> there is an existing lock in place to address this issue, though we are
>>> looking to refactor the code over time to remove and/or limit how these
>>> flags are used.
>>
>> Can you share more details about the race? If there is no lock in place
>> there's always the risk that:
>>
>> CPU 0 CPU 1
>> idpf_vport_stop() whatever()
>> if (test_bit(UP))
>> # sees true
>> # !< long IRQ arrives
>> test_and_clear(UP)
>> ...
>> all the rest
>> ...
>> # > long IRQ ends
>> proceed but UP isn't really set any more
>>
>
> The specific case I was targeting with this patch is for when both
> idpf_vport_stop() and idpf_addr_unsync(), called via set_rx_mode attempt
> to delete the MAC filters. At least in my testing I have not seen a case
> where the set_rx_mode callback will happen before idpf_vport_stop(). I
> am assuming due to userspace reacting to the removal of the netdevs.
>
> rmmod-6089 [021] ..... 3521.291596: idpf_remove
> <-pci_device_remove
> rmmod-6089 [021] ..... 3521.292686: idpf_vport_stop
> <-idpf_vport_dealloc
> systemd-resolve-1633 [022] b..1. 3521.295320: idpf_set_rx_mode
> <-dev_mc_del
> systemd-resolve-1633 [022] b..1. 3521.295338: idpf_addr_unsync
> <-__hw_addr_sync_dev
> systemd-resolve-1633 [022] b..1. 3521.295339: idpf_del_mac_filter
> <-idpf_addr_unsync
> systemd-resolve-1633 [022] b..1. 3521.295450: idpf_set_rx_mode
> <-dev_mc_del
> systemd-resolve-1633 [022] b..1. 3521.295451: idpf_addr_unsync
> <-__hw_addr_sync_dev
> systemd-resolve-1633 [022] b..1. 3521.295451: idpf_del_mac_filter
> <-idpf_addr_unsync
> rmmod-6089 [002] ..... 3521.934980: idpf_vport_stop
> <-idpf_vport_dealloc
> systemd-resolve-1633 [022] b..1. 3522.297299: idpf_set_rx_mode
> <-dev_mc_del
> systemd-resolve-1633 [022] b..1. 3522.297316: idpf_addr_unsync
> <-__hw_addr_sync_dev
> systemd-resolve-1633 [022] b..1. 3522.297317: idpf_del_mac_filter
> <-idpf_addr_unsync
> kworker/u261:2-3157 [037] ...1. 3522.297931:
> idpf_mac_filter_async_handler: Received invalid MAC filter payload (op
> 536) (len 0)
> rmmod-6089 [020] ..... 3522.573251: idpf_vport_stop
> <-idpf_vport_dealloc
> rmmod-6089 [002] ..... 3523.229936: idpf_vport_stop
> <-idpf_vport_dealloc
> systemd-resolve-1633 [022] b..1. 3523.311435: idpf_set_rx_mode
> <-dev_mc_del
> systemd-resolve-1633 [022] b..1. 3523.311452: idpf_addr_unsync
> <-__hw_addr_sync_dev
> systemd-resolve-1633 [022] b..1. 3523.311453: idpf_del_mac_filter
> <-idpf_addr_unsync
>
>
Jakub, from this thread it still seems like you won't accept this patch
as-is?
I'm working on a v3 of this series resolving the other issues Simon
pointed out, and want to know if I should continue excluding Emil's
patches for now.
Thanks,
Jake
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH net 3/8] idpf: fix possible race in idpf_vport_stop()
2025-10-08 21:41 ` Jacob Keller
@ 2025-10-13 18:13 ` Jakub Kicinski
2025-10-22 22:49 ` Tantilov, Emil S
0 siblings, 1 reply; 21+ messages in thread
From: Jakub Kicinski @ 2025-10-13 18:13 UTC (permalink / raw)
To: Jacob Keller
Cc: Tantilov, Emil S, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Paolo Abeni, Pavan Kumar Linga, Alexander Lobakin,
Willem de Bruijn, Sridhar Samudrala, Phani Burra,
Piotr Kwapulinski, Simon Horman, Radoslaw Tyl, Jedrzej Jagielski,
Mateusz Polchlopek, Anton Nadezhdin, Konstantin Ilichev,
Milena Olech, netdev, linux-kernel, Joshua Hay,
Aleksandr Loktionov, Chittim Madhu, Samuel Salin
On Wed, 8 Oct 2025 14:41:40 -0700 Jacob Keller wrote:
> Jakub, from this thread it still seems like you won't accept this patch
> as-is?
I haven't analyzed Emil's response. I hope my concern is clear enough
(at least to you). If the code is provably safe I think the patch itself
can go in, we just need a much better commit msg.
^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [PATCH net 3/8] idpf: fix possible race in idpf_vport_stop()
2025-10-13 18:13 ` Jakub Kicinski
@ 2025-10-22 22:49 ` Tantilov, Emil S
0 siblings, 0 replies; 21+ messages in thread
From: Tantilov, Emil S @ 2025-10-22 22:49 UTC (permalink / raw)
To: Jakub Kicinski, Jacob Keller
Cc: Przemek Kitszel, Andrew Lunn, David S. Miller, Eric Dumazet,
Paolo Abeni, Pavan Kumar Linga, Alexander Lobakin,
Willem de Bruijn, Sridhar Samudrala, Phani Burra,
Piotr Kwapulinski, Simon Horman, Radoslaw Tyl, Jedrzej Jagielski,
Mateusz Polchlopek, Anton Nadezhdin, Konstantin Ilichev,
Milena Olech, netdev, linux-kernel, Joshua Hay,
Aleksandr Loktionov, Chittim Madhu, Samuel Salin, Tony Nguyen
On 10/13/2025 11:13 AM, Jakub Kicinski wrote:
> On Wed, 8 Oct 2025 14:41:40 -0700 Jacob Keller wrote:
>> Jakub, from this thread it still seems like you won't accept this patch
>> as-is?
>
> I haven't analyzed Emil's response. I hope my concern is clear enough
> (at least to you). If the code is provably safe I think the patch itself
> can go in, we just need a much better commit msg.
Actually we can drop this patch as the issue it is fixing is no longer
reproducible, following the introduction of the RTNL parameter to
idpf_vport_stop() by Olek:
https://lore.kernel.org/netdev/20250908195748.1707057-5-anthony.l.nguyen@intel.com/
I would still like to keep the first patch in this series:
https://lore.kernel.org/netdev/20250822035248.22969-2-emil.s.tantilov@intel.com/
I will rebase it and resend for -next unless there are objections.
Thanks,
Emil
^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2025-10-22 22:49 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-10-02 0:14 [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf) Jacob Keller
2025-10-02 0:14 ` [PATCH net 1/8] idpf: cleanup remaining SKBs in PTP flows Jacob Keller
2025-10-02 0:14 ` [PATCH net 2/8] idpf: convert vport state to bitmap Jacob Keller
2025-10-02 0:14 ` [PATCH net 3/8] idpf: fix possible race in idpf_vport_stop() Jacob Keller
2025-10-03 17:43 ` Jakub Kicinski
2025-10-06 14:49 ` Tantilov, Emil S
2025-10-06 17:26 ` Jakub Kicinski
2025-10-07 0:07 ` Tantilov, Emil S
2025-10-08 21:41 ` Jacob Keller
2025-10-13 18:13 ` Jakub Kicinski
2025-10-22 22:49 ` Tantilov, Emil S
2025-10-02 0:14 ` [PATCH net 4/8] ixgbevf: fix getting link speed data for E610 devices Jacob Keller
2025-10-02 0:14 ` [PATCH net 5/8] ixgbe: handle IXGBE_VF_GET_PF_LINK_STATE mailbox operation Jacob Keller
2025-10-02 0:14 ` [PATCH net 6/8] ixgbevf: fix mailbox API compatibility by negotiating supported features Jacob Keller
2025-10-02 0:14 ` [PATCH net 7/8] ixgbe: handle IXGBE_VF_FEATURES_NEGOTIATE mbox cmd Jacob Keller
2025-10-02 0:14 ` [PATCH net 8/8] ixgbe: fix too early devlink_free() in ixgbe_remove() Jacob Keller
2025-10-03 17:42 ` [PATCH net 0/8] Intel Wired LAN Driver Updates 2025-10-01 (idpf, ixgbe, ixgbevf) Jakub Kicinski
2025-10-04 0:58 ` Jacob Keller
2025-10-06 15:27 ` Alexander Lobakin
2025-10-06 21:59 ` Jacob Keller
2025-10-06 23:58 ` Jacob Keller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).