* [PATCH net v1 0/3] af_packet/tcp: fix late hardware timestamp handling
From: Kohei Enju @ 2026-04-29 9:16 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, Willem de Bruijn, David Ahern,
Neal Cardwell, Gerhard Engleder, Jonathan Lemon, Richard Cochran,
Kohei Enju
Since commit 97dc7cd92ac6 ("ptp: Support late timestamp determination"),
skb_shared_hwtstamps may carry netdev_data instead of a resolved
hwtstamp. AF_PACKET and TCP could still read that storage as a ktime_t
and report bogus hardware timestamps to userspace.
This series factors the late timestamp resolution logic into a common
helper, then switches AF_PACKET and TCP to use it.
Notes on SOF_TIMESTAMPING_BIND_PHC:
The generic socket receive timestamping path honors it, but the
AF_PACKET and TCP receive paths touched here haven't implemented that
behavior.
This series doesn't change that; those paths always resolve timestamps
with cycles == false and preserve their timestamp-domain semantics.
Kohei Enju (3):
net: introduce helper to resolve hardware timestamps from skb
af_packet: use skb_get_hwtstamp() for hardware timestamps
tcp: use skb_get_hwtstamp() for hardware timestamps
include/linux/skbuff.h | 11 +++++++++++
include/net/tcp.h | 2 +-
net/core/skbuff.c | 27 +++++++++++++++++++++++++++
net/ipv4/tcp_input.c | 3 ++-
net/ipv4/tcp_ipv4.c | 6 ++++--
net/ipv6/tcp_ipv6.c | 3 ++-
net/packet/af_packet.c | 2 +-
net/socket.c | 27 +++------------------------
8 files changed, 51 insertions(+), 30 deletions(-)
--
2.53.0
^ permalink raw reply
* [PATCH net v1 2/3] af_packet: use skb_get_hwtstamp() for hardware timestamps
From: Kohei Enju @ 2026-04-29 9:16 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, Willem de Bruijn, David Ahern,
Neal Cardwell, Gerhard Engleder, Jonathan Lemon, Richard Cochran,
Kohei Enju
In-Reply-To: <20260429091632.26509-1-kohei@enjuk.jp>
Since commit 97dc7cd92ac6 ("ptp: Support late timestamp determination"),
skb_shared_hwtstamps may contain netdev_data instead of hwtstamp.
tpacket_get_timestamp() unconditionally interprets skb_shared_hwtstamps
as a resolved hardware timestamp, and can report bogus hardware
timestamps to userspace.
Use skb_get_hwtstamp() instead of reading hwtstamp directly, so packet
sockets follow the same hardware timestamp resolution path as the socket
layer.
Note that skb_get_hwtstamp() is called with cycles == false, since
AF_PACKET hasn't honored SOF_TIMESTAMPING_BIND_PHC so far, and this
patch doesn't change that behavior.
Fixes: 97dc7cd92ac6 ("ptp: Support late timestamp determination")
Signed-off-by: Kohei Enju <kohei@enjuk.jp>
---
net/packet/af_packet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index 8e6f3a734ba0..e88bc3f1156f 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
@@ -458,7 +458,7 @@ static __u32 tpacket_get_timestamp(struct sk_buff *skb, struct timespec64 *ts,
if (shhwtstamps &&
(flags & SOF_TIMESTAMPING_RAW_HARDWARE) &&
- ktime_to_timespec64_cond(shhwtstamps->hwtstamp, ts))
+ ktime_to_timespec64_cond(skb_get_hwtstamp(skb, false, NULL), ts))
return TP_STATUS_TS_RAW_HARDWARE;
if ((flags & SOF_TIMESTAMPING_SOFTWARE) &&
--
2.53.0
^ permalink raw reply related
* [PATCH net v1 1/3] net: introduce helper to resolve hardware timestamps from skb
From: Kohei Enju @ 2026-04-29 9:16 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, Willem de Bruijn, David Ahern,
Neal Cardwell, Gerhard Engleder, Jonathan Lemon, Richard Cochran,
Kohei Enju
In-Reply-To: <20260429091632.26509-1-kohei@enjuk.jp>
Move the logic that resolves a hardware timestamp from an skb, including
late timestamp resolution via netdev_get_tstamp(), from net/socket.c to
a common helper.
Let's allow other networking code to reuse the same resolution path.
Signed-off-by: Kohei Enju <kohei@enjuk.jp>
---
include/linux/skbuff.h | 11 +++++++++++
net/core/skbuff.c | 27 +++++++++++++++++++++++++++
net/socket.c | 27 +++------------------------
3 files changed, 41 insertions(+), 24 deletions(-)
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 2bcf78a4de7b..651a5ae8b11c 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -4731,6 +4731,17 @@ void __skb_tstamp_tx(struct sk_buff *orig_skb, const struct sk_buff *ack_skb,
void skb_tstamp_tx(struct sk_buff *orig_skb,
struct skb_shared_hwtstamps *hwtstamps);
+/**
+ * skb_get_hwtstamp - resolve a hardware timestamp from an skb
+ * @skb: skb carrying the timestamp
+ * @cycles: true to request the free-running cycle-based timestamp
+ * @if_index: optional return pointer for the originating netdev ifindex
+ *
+ * Return: resolved hardware timestamp, or the stored skb hwtstamp when no
+ * device-specific late timestamp resolution is needed.
+ */
+ktime_t skb_get_hwtstamp(struct sk_buff *skb, bool cycles, int *if_index);
+
/**
* skb_tx_timestamp() - Driver hook for transmit timestamping
*
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 7dad68e3b518..d11f4e2e9391 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -5729,6 +5729,33 @@ void skb_tstamp_tx(struct sk_buff *orig_skb,
}
EXPORT_SYMBOL_GPL(skb_tstamp_tx);
+ktime_t skb_get_hwtstamp(struct sk_buff *skb, bool cycles, int *if_index)
+{
+ struct skb_shared_hwtstamps *shhwtstamps = skb_hwtstamps(skb);
+ struct net_device *orig_dev;
+ ktime_t hwtstamp;
+
+ if (if_index)
+ *if_index = 0;
+
+ if (!(skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP_NETDEV))
+ return shhwtstamps->hwtstamp;
+
+ rcu_read_lock();
+ orig_dev = dev_get_by_napi_id(skb_napi_id(skb));
+ if (orig_dev) {
+ if (if_index)
+ *if_index = orig_dev->ifindex;
+ hwtstamp = netdev_get_tstamp(orig_dev, shhwtstamps, cycles);
+ } else {
+ hwtstamp = shhwtstamps->hwtstamp;
+ }
+ rcu_read_unlock();
+
+ return hwtstamp;
+}
+EXPORT_SYMBOL_GPL(skb_get_hwtstamp);
+
#ifdef CONFIG_WIRELESS
void skb_complete_wifi_ack(struct sk_buff *skb, bool acked)
{
diff --git a/net/socket.c b/net/socket.c
index 22a412fdec07..95b21b16a0fc 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -876,21 +876,7 @@ static bool skb_is_swtx_tstamp(const struct sk_buff *skb, int false_tstamp)
static ktime_t get_timestamp(struct sock *sk, struct sk_buff *skb, int *if_index)
{
bool cycles = READ_ONCE(sk->sk_tsflags) & SOF_TIMESTAMPING_BIND_PHC;
- struct skb_shared_hwtstamps *shhwtstamps = skb_hwtstamps(skb);
- struct net_device *orig_dev;
- ktime_t hwtstamp;
-
- rcu_read_lock();
- orig_dev = dev_get_by_napi_id(skb_napi_id(skb));
- if (orig_dev) {
- *if_index = orig_dev->ifindex;
- hwtstamp = netdev_get_tstamp(orig_dev, shhwtstamps, cycles);
- } else {
- hwtstamp = shhwtstamps->hwtstamp;
- }
- rcu_read_unlock();
-
- return hwtstamp;
+ return skb_get_hwtstamp(skb, cycles, if_index);
}
static void put_ts_pktinfo(struct msghdr *msg, struct sk_buff *skb,
@@ -940,7 +926,6 @@ int skb_get_tx_timestamp(struct sk_buff *skb, struct sock *sk,
{
u32 tsflags = READ_ONCE(sk->sk_tsflags);
ktime_t hwtstamp;
- int if_index = 0;
if ((tsflags & SOF_TIMESTAMPING_SOFTWARE) &&
ktime_to_timespec64_cond(skb->tstamp, ts))
@@ -950,10 +935,7 @@ int skb_get_tx_timestamp(struct sk_buff *skb, struct sock *sk,
skb_is_swtx_tstamp(skb, false))
return -ENOENT;
- if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP_NETDEV)
- hwtstamp = get_timestamp(sk, skb, &if_index);
- else
- hwtstamp = skb_hwtstamps(skb)->hwtstamp;
+ hwtstamp = get_timestamp(sk, skb, NULL);
if (tsflags & SOF_TIMESTAMPING_BIND_PHC)
hwtstamp = ptp_convert_timestamp(&hwtstamp,
@@ -1033,10 +1015,7 @@ void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
!(tsflags & SOF_TIMESTAMPING_OPT_RX_FILTER))) &&
!skb_is_swtx_tstamp(skb, false_tstamp)) {
if_index = 0;
- if (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP_NETDEV)
- hwtstamp = get_timestamp(sk, skb, &if_index);
- else
- hwtstamp = shhwtstamps->hwtstamp;
+ hwtstamp = get_timestamp(sk, skb, &if_index);
if (tsflags & SOF_TIMESTAMPING_BIND_PHC)
hwtstamp = ptp_convert_timestamp(&hwtstamp,
--
2.53.0
^ permalink raw reply related
* [PATCH net v1 3/3] tcp: use skb_get_hwtstamp() for hardware timestamps
From: Kohei Enju @ 2026-04-29 9:16 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Kuniyuki Iwashima, Willem de Bruijn, David Ahern,
Neal Cardwell, Gerhard Engleder, Jonathan Lemon, Richard Cochran,
Kohei Enju
In-Reply-To: <20260429091632.26509-1-kohei@enjuk.jp>
Since commit 97dc7cd92ac6 ("ptp: Support late timestamp determination"),
skb_shared_hwtstamps may contain netdev_data instead of hwtstamp. TCP
receive timestamping can then interpret the stored value as a ktime_t
and report bogus hardware timestamps to userspace.
Use skb_get_hwtstamp() instead of reading hwtstamp directly, so TCP
sockets follow the same hardware timestamp resolution path as the socket
layer. When coalescing SKBs, resolve late timestamps before copying them
to the merged skb. Additionally, recognize SKBTX_HW_TSTAMP_NETDEV as
indicating a receive timestamp is present.
Note that skb_get_hwtstamp() is called with cycles == false, since TCP
hasn't honored SOF_TIMESTAMPING_BIND_PHC so far, and this patch doesn't
change that behavior.
Fixes: 97dc7cd92ac6 ("ptp: Support late timestamp determination")
Signed-off-by: Kohei Enju <kohei@enjuk.jp>
---
include/net/tcp.h | 2 +-
net/ipv4/tcp_input.c | 3 ++-
net/ipv4/tcp_ipv4.c | 6 ++++--
net/ipv6/tcp_ipv6.c | 3 ++-
4 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/include/net/tcp.h b/include/net/tcp.h
index ecbadcb3a744..7b5fcee97079 100644
--- a/include/net/tcp.h
+++ b/include/net/tcp.h
@@ -524,7 +524,7 @@ tcp_update_recv_tstamps(struct sk_buff *skb,
struct scm_timestamping_internal *tss)
{
tss->ts[0] = skb->tstamp;
- tss->ts[2] = skb_hwtstamps(skb)->hwtstamp;
+ tss->ts[2] = skb_get_hwtstamp(skb, false, NULL);
}
void tcp_recv_timestamp(struct msghdr *msg, const struct sock *sk,
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index d5c9e65d9760..9fd473559b58 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -5237,7 +5237,8 @@ static bool tcp_try_coalesce(struct sock *sk,
if (TCP_SKB_CB(from)->has_rxtstamp) {
TCP_SKB_CB(to)->has_rxtstamp = true;
to->tstamp = from->tstamp;
- skb_hwtstamps(to)->hwtstamp = skb_hwtstamps(from)->hwtstamp;
+ skb_hwtstamps(to)->hwtstamp = skb_get_hwtstamp(from, false, NULL);
+ skb_shinfo(to)->tx_flags &= ~SKBTX_HW_TSTAMP_NETDEV;
}
return true;
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index 8fc24c3743c5..c35d82317764 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -1993,7 +1993,8 @@ enum skb_drop_reason tcp_add_backlog(struct sock *sk, struct sk_buff *skb)
if (TCP_SKB_CB(skb)->has_rxtstamp) {
TCP_SKB_CB(tail)->has_rxtstamp = true;
tail->tstamp = skb->tstamp;
- skb_hwtstamps(tail)->hwtstamp = skb_hwtstamps(skb)->hwtstamp;
+ skb_hwtstamps(tail)->hwtstamp = skb_get_hwtstamp(skb, false, NULL);
+ skb_shinfo(tail)->tx_flags &= ~SKBTX_HW_TSTAMP_NETDEV;
}
/* Not as strict as GRO. We only need to carry mss max value */
@@ -2062,7 +2063,8 @@ static void tcp_v4_fill_cb(struct sk_buff *skb, const struct iphdr *iph,
TCP_SKB_CB(skb)->ip_dsfield = ipv4_get_dsfield(iph);
TCP_SKB_CB(skb)->sacked = 0;
TCP_SKB_CB(skb)->has_rxtstamp =
- skb->tstamp || skb_hwtstamps(skb)->hwtstamp;
+ skb->tstamp || skb_hwtstamps(skb)->hwtstamp ||
+ (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP_NETDEV);
}
/*
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index 2c3f7a739709..3361ed7f94de 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -1704,7 +1704,8 @@ static void tcp_v6_fill_cb(struct sk_buff *skb, const struct ipv6hdr *hdr,
TCP_SKB_CB(skb)->ip_dsfield = ipv6_get_dsfield(hdr);
TCP_SKB_CB(skb)->sacked = 0;
TCP_SKB_CB(skb)->has_rxtstamp =
- skb->tstamp || skb_hwtstamps(skb)->hwtstamp;
+ skb->tstamp || skb_hwtstamps(skb)->hwtstamp ||
+ (skb_shinfo(skb)->tx_flags & SKBTX_HW_TSTAMP_NETDEV);
}
INDIRECT_CALLABLE_SCOPE int tcp_v6_rcv(struct sk_buff *skb)
--
2.53.0
^ permalink raw reply related
* RE: [Intel-wired-lan] [PATCH 1/2] ice: allow creating VFs when !CONFIG_ICE_SWITCHDEV
From: Loktionov, Aleksandr @ 2026-04-29 9:17 UTC (permalink / raw)
To: Vincent Chen, Nguyen, Anthony L, Kitszel, Przemyslaw
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org
In-Reply-To: <20260429065127.423949-2-vincent.chen@sifive.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Vincent Chen via Intel-wired-lan
> Sent: Wednesday, April 29, 2026 8:51 AM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>
> Cc: andrew+netdev@lunn.ch; davem@davemloft.net; edumazet@google.com;
> kuba@kernel.org; pabeni@redhat.com; intel-wired-lan@lists.osuosl.org;
> netdev@vger.kernel.org; vincent.chen@sifive.com
> Subject: [Intel-wired-lan] [PATCH 1/2] ice: allow creating VFs when
> !CONFIG_ICE_SWITCHDEV
>
> Currently ice_eswitch_attach_vf() is called unconditionally in
> ice_start_vfs(), which causes VF creation to fail when
> CONFIG_ICE_SWITCHDEV is not defined.
>
> Fix this by adding switchdev mode checks at the call sites before
> calling ice_eswitch_attach_vf(), consistent with how
> ice_eswitch_attach_sf() is already handled in ice_devlink_port_new().
> This is similar to commit aacca7a83b97 ("ice: allow creating VFs for
> !CONFIG_NET_SWITCHDEV") which fixed the same issue for the previous
> ice_eswitch_configure() API.
>
> Signed-off-by: Vincent Chen <vincent.chen@sifive.com>
> ---
> drivers/net/ethernet/intel/ice/ice_sriov.c | 14 ++++++++------
> drivers/net/ethernet/intel/ice/ice_vf_lib.c | 3 ++-
> 2 files changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c
> b/drivers/net/ethernet/intel/ice/ice_sriov.c
> index 843e82fd3bf9..6a0b724e46f9 100644
> --- a/drivers/net/ethernet/intel/ice/ice_sriov.c
> +++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
> @@ -484,12 +484,14 @@ static int ice_start_vfs(struct ice_pf *pf)
> goto teardown;
> }
>
> - retval = ice_eswitch_attach_vf(pf, vf);
> - if (retval) {
> - dev_err(ice_pf_to_dev(pf), "Failed to attach VF
> %d to eswitch, error %d",
> - vf->vf_id, retval);
> - ice_vf_vsi_release(vf);
> - goto teardown;
> + if (ice_is_eswitch_mode_switchdev(pf)) {
> + retval = ice_eswitch_attach_vf(pf, vf);
> + if (retval) {
> + dev_err(ice_pf_to_dev(pf), "Failed to
> attach VF %d to eswitch, error %d",
> + vf->vf_id, retval);
> + ice_vf_vsi_release(vf);
> + goto teardown;
> + }
> }
>
> set_bit(ICE_VF_STATE_INIT, vf->vf_states); diff --git
> a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
> b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
> index de9e81ccee66..71595410174c 100644
> --- a/drivers/net/ethernet/intel/ice/ice_vf_lib.c
> +++ b/drivers/net/ethernet/intel/ice/ice_vf_lib.c
> @@ -807,7 +807,8 @@ void ice_reset_all_vfs(struct ice_pf *pf)
> ice_vf_rebuild_vsi(vf);
> ice_vf_post_vsi_rebuild(vf);
>
> - ice_eswitch_attach_vf(pf, vf);
> + if (ice_is_eswitch_mode_switchdev(pf))
> + ice_eswitch_attach_vf(pf, vf);
>
> mutex_unlock(&vf->cfg_lock);
> }
> --
> 2.34.1
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH 2/2] ice: remove redundant switchdev check in ice_eswitch_attach_vf()
From: Loktionov, Aleksandr @ 2026-04-29 9:18 UTC (permalink / raw)
To: Vincent Chen, Nguyen, Anthony L, Kitszel, Przemyslaw
Cc: andrew+netdev@lunn.ch, davem@davemloft.net, edumazet@google.com,
kuba@kernel.org, pabeni@redhat.com,
intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org
In-Reply-To: <20260429065127.423949-3-vincent.chen@sifive.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Vincent Chen via Intel-wired-lan
> Sent: Wednesday, April 29, 2026 8:51 AM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>
> Cc: andrew+netdev@lunn.ch; davem@davemloft.net; edumazet@google.com;
> kuba@kernel.org; pabeni@redhat.com; intel-wired-lan@lists.osuosl.org;
> netdev@vger.kernel.org; vincent.chen@sifive.com
> Subject: [Intel-wired-lan] [PATCH 2/2] ice: remove redundant switchdev
> check in ice_eswitch_attach_vf()
>
> All callers of ice_eswitch_attach_vf() check the switchdev mode before
> calling the function, the internal switchdev mode check in
> ice_eswitch_attach_vf() is redundant. Remove this check to align with
> the design pattern used for ice_eswitch_attach_sf(), where the caller
> is responsible for checking switchdev mode before attachment.
>
> Signed-off-by: Vincent Chen <vincent.chen@sifive.com>
> ---
> drivers/net/ethernet/intel/ice/ice_eswitch.c | 3 ---
> 1 file changed, 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_eswitch.c
> b/drivers/net/ethernet/intel/ice/ice_eswitch.c
> index 2e4f0969035f..c709decb26d5 100644
> --- a/drivers/net/ethernet/intel/ice/ice_eswitch.c
> +++ b/drivers/net/ethernet/intel/ice/ice_eswitch.c
> @@ -512,9 +512,6 @@ int ice_eswitch_attach_vf(struct ice_pf *pf,
> struct ice_vf *vf)
> struct ice_repr *repr;
> int err;
>
> - if (!ice_is_eswitch_mode_switchdev(pf))
> - return 0;
> -
> repr = ice_repr_create_vf(vf);
> if (IS_ERR(repr))
> return PTR_ERR(repr);
> --
> 2.34.1
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net-next] net: Consistently define pci_device_ids using named initializers
From: Loktionov, Aleksandr @ 2026-04-29 9:19 UTC (permalink / raw)
To: Uwe Kleine-König (The Capable Hub), Michael Grzeschik,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Marc Kleine-Budde, Vincent Mailhol, Krzysztof Halasa,
Johannes Berg
Cc: Richard Cochran, Yonglong Liu, Kees Cook,
linux-wireless@vger.kernel.org, Zaremba, Larysa,
brcm80211@lists.linux.dev, Daniele Venzano,
oss-drivers@corigine.com, Nguyen, Anthony L, MD Danish Anwar,
Samuel Chessman, Fan Gong, Marco Crivellari, Kevin Curtis,
Ingo Molnar, Ion Badulescu, Shevchenko, Andriy, Leon Romanovsky,
Colin Ian King, Kitszel, Przemyslaw, Peiyang Wang, Thomas Fourier,
Sai Krishna, Denis Kirjanov, intel-wired-lan@lists.osuosl.org,
linux-parisc@vger.kernel.org, Keller, Jacob E, Mengyuan Lou,
Steffen Klassert, Stanislav Yakovlev, linux-rdma@vger.kernel.org,
Arend van Spriel, nic_swsd@realtek.com, Jiri Pirko,
Philipp Stanner, Chi-hsien Lin, Ido Schimmel, Potnuri Bharat Teja,
Double Lo, Markus Schneider-Pargmann, Nathan Chancellor,
Jiawen Wu, Cai Huoqing, Bjorn Helgaas, Zilin Guan,
linux-can@vger.kernel.org, Yibo Dong, Joe Damato, Petr Machata,
Kory Maincent, brcm80211-dev-list.pdl@broadcom.com,
GR-Linux-NIC-Dev@marvell.com, Vadim Fedorenko, Manish Chopra,
Denis Benato, Rasesh Mody, netdev@vger.kernel.org, Randy Dunlap,
Mark Bloch, linux-kernel@vger.kernel.org, Tariq Toukan, Jian Shen,
Jijie Shao, Yeounsu Moon, Thomas Gleixner, Simon Horman,
Yicong Hui, Mark Einon, Ethan Nelson-Moore, Saeed Mahameed,
Sudarsana Kalluru, Heiner Kallweit
In-Reply-To: <20260428171845.2288395-2-u.kleine-koenig@baylibre.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Uwe Kleine-König (The Capable Hub)
> Sent: Tuesday, April 28, 2026 7:19 PM
> To: Michael Grzeschik <m.grzeschik@pengutronix.de>; 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>; Marc Kleine-Budde <mkl@pengutronix.de>;
> Vincent Mailhol <mailhol@kernel.org>; Krzysztof Halasa
> <khc@pm.waw.pl>; Johannes Berg <johannes@sipsolutions.net>
> Cc: Richard Cochran <richardcochran@gmail.com>; Yonglong Liu
> <liuyonglong@huawei.com>; Kees Cook <kees@kernel.org>; linux-
> wireless@vger.kernel.org; Zaremba, Larysa <larysa.zaremba@intel.com>;
> brcm80211@lists.linux.dev; Daniele Venzano <venza@brownhat.org>; oss-
> drivers@corigine.com; Nguyen, Anthony L <anthony.l.nguyen@intel.com>;
> MD Danish Anwar <danishanwar@ti.com>; Samuel Chessman
> <chessman@tux.org>; Fan Gong <gongfan1@huawei.com>; Marco Crivellari
> <marco.crivellari@suse.com>; Kevin Curtis
> <kevin.curtis@farsite.co.uk>; Ingo Molnar <mingo@kernel.org>; Ion
> Badulescu <ionut@badula.org>; Shevchenko, Andriy
> <andriy.shevchenko@intel.com>; Leon Romanovsky <leon@kernel.org>;
> Colin Ian King <colin.i.king@gmail.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Peiyang Wang
> <wangpeiyang1@huawei.com>; Thomas Fourier <fourier.thomas@gmail.com>;
> Sai Krishna <saikrishnag@marvell.com>; Denis Kirjanov
> <kirjanov@gmail.com>; intel-wired-lan@lists.osuosl.org; linux-
> parisc@vger.kernel.org; Keller, Jacob E <jacob.e.keller@intel.com>;
> Mengyuan Lou <mengyuanlou@net-swift.com>; Steffen Klassert
> <klassert@kernel.org>; Stanislav Yakovlev <stas.yakovlev@gmail.com>;
> linux-rdma@vger.kernel.org; Arend van Spriel
> <arend.vanspriel@broadcom.com>; nic_swsd@realtek.com; Jiri Pirko
> <jiri@resnulli.us>; Philipp Stanner <phasta@kernel.org>; Chi-hsien Lin
> <chi-hsien.lin@cypress.com>; Ido Schimmel <idosch@nvidia.com>; Potnuri
> Bharat Teja <bharat@chelsio.com>; Double Lo <double.lo@cypress.com>;
> Markus Schneider-Pargmann <msp@baylibre.com>; Nathan Chancellor
> <nathan@kernel.org>; Jiawen Wu <jiawenwu@trustnetic.com>; Cai Huoqing
> <cai.huoqing@linux.dev>; Bjorn Helgaas <bhelgaas@google.com>; Zilin
> Guan <zilin@seu.edu.cn>; linux-can@vger.kernel.org; Yibo Dong
> <dong100@mucse.com>; Joe Damato <joe@dama.to>; Petr Machata
> <petrm@nvidia.com>; Kory Maincent <kory.maincent@bootlin.com>;
> brcm80211-dev-list.pdl@broadcom.com; GR-Linux-NIC-Dev@marvell.com;
> Vadim Fedorenko <vadim.fedorenko@linux.dev>; Manish Chopra
> <manishc@marvell.com>; Denis Benato <benato.denis96@gmail.com>; Rasesh
> Mody <rmody@marvell.com>; netdev@vger.kernel.org; Randy Dunlap
> <rdunlap@infradead.org>; Mark Bloch <mbloch@nvidia.com>; linux-
> kernel@vger.kernel.org; Tariq Toukan <tariqt@nvidia.com>; Jian Shen
> <shenjian15@huawei.com>; Jijie Shao <shaojijie@huawei.com>; Yeounsu
> Moon <yyyynoom@gmail.com>; Thomas Gleixner <tglx@kernel.org>; Simon
> Horman <horms@kernel.org>; Yicong Hui <yiconghui@gmail.com>; Mark
> Einon <mark.einon@gmail.com>; Ethan Nelson-Moore
> <enelsonmoore@gmail.com>; Saeed Mahameed <saeedm@nvidia.com>;
> Sudarsana Kalluru <skalluru@marvell.com>; Heiner Kallweit
> <hkallweit1@gmail.com>
> Subject: [Intel-wired-lan] [PATCH net-next] net: Consistently define
> pci_device_ids using named initializers
>
> ... and PCI device helpers.
>
> The various struct pci_device_id arrays were initialized mostly by one
> the PCI_DEVICE macros and then list expressions. The latter isn't
> easily
> readable if you're not into PCI. Using named initializers is more
> explicit and thus easier to parse.
>
> Also use PCI_DEVICE* helper macros to assign .vendor, .device,
> .subvendor and .subdevice where appropriate and skip explicit
> assignments of 0 (which the compiler takes care of).
>
> The secret plan is to make struct pci_device_id::driver_data an
> anonymous union (similar to
> https://lore.kernel.org/all/cover.1776579304.git.u.kleine-
> koenig@baylibre.com/)
> and that requires named initializers. But it's also a nice cleanup on
> its own.
>
> This change doesn't introduce changes to the compiled pci_device_id
> arrays. Tested on x86 and arm64.
>
> Signed-off-by: Uwe Kleine-König (The Capable Hub) <u.kleine-
> koenig@baylibre.com>
> ---
> Hello,
>
> the mentioned follow-up quest allows to do
>
> PCI_DEVICE(0x1571, 0xa203),
> + .driver_data = (kernel_ulong_t)&card_info_10mbit,
> - .driver_data_ptr = &card_info_10mbit,
>
> which gets rid of a bunch of casts and so brings a little bit more
> type
> safety. This patch is a preparation for that.
>
> I handled all of drivers/net/ in a single patch, please tell me if I
> should split by subsystem.
>
> Best regards
> Uwe
> ---
> drivers/net/arcnet/com20020-pci.c | 242 +++------
> drivers/net/can/m_can/m_can_pci.c | 6 +-
> drivers/net/can/sja1000/plx_pci.c | 167 +++----
> drivers/net/ethernet/3com/3c59x.c | 80 +--
> drivers/net/ethernet/3com/typhoon.c | 75 ++-
> drivers/net/ethernet/8390/ne2k-pci.c | 24 +-
> drivers/net/ethernet/adaptec/starfire.c | 4 +-
> drivers/net/ethernet/agere/et131x.c | 6 +-
> drivers/net/ethernet/broadcom/bnx2.c | 62 ++-
> .../net/ethernet/broadcom/bnx2x/bnx2x_main.c | 50 +-
> .../net/ethernet/cavium/liquidio/lio_main.c | 10 +-
> .../ethernet/cavium/liquidio/lio_vf_main.c | 7 +-
> drivers/net/ethernet/chelsio/cxgb/common.h | 2 +-
> drivers/net/ethernet/chelsio/cxgb/subr.c | 2 +-
> .../net/ethernet/chelsio/cxgb3/cxgb3_main.c | 4 +-
> .../net/ethernet/chelsio/cxgb4/cxgb4_main.c | 4 +-
> .../ethernet/chelsio/cxgb4vf/cxgb4vf_main.c | 4 +-
> drivers/net/ethernet/dec/tulip/de2104x.c | 6 +-
> drivers/net/ethernet/dec/tulip/dmfe.c | 12 +-
> drivers/net/ethernet/dec/tulip/tulip_core.c | 78 +--
> drivers/net/ethernet/dec/tulip/uli526x.c | 6 +-
> drivers/net/ethernet/dec/tulip/winbond-840.c | 13 +-
> drivers/net/ethernet/dlink/dl2k.h | 12 +-
> drivers/net/ethernet/dlink/sundance.c | 14 +-
> drivers/net/ethernet/fealnx.c | 8 +-
> .../net/ethernet/hisilicon/hibmcge/hbg_main.c | 2 +-
> .../net/ethernet/hisilicon/hns3/hns3_enet.c | 50 +-
> .../hisilicon/hns3/hns3pf/hclge_main.c | 18 +-
> .../hisilicon/hns3/hns3vf/hclgevf_main.c | 12 +-
> .../net/ethernet/huawei/hinic/hinic_main.c | 12 +-
> .../net/ethernet/huawei/hinic3/hinic3_lld.c | 7 +-
> drivers/net/ethernet/intel/e100.c | 4 +-
> drivers/net/ethernet/intel/e1000e/netdev.c | 471 +++++++++++++----
> -
> drivers/net/ethernet/intel/fm10k/fm10k_pci.c | 10 +-
> drivers/net/ethernet/intel/i40e/i40e_main.c | 59 +--
> drivers/net/ethernet/intel/iavf/iavf_main.c | 10 +-
> drivers/net/ethernet/intel/igb/igb_main.c | 66 +--
> drivers/net/ethernet/intel/igbvf/netdev.c | 4 +-
> drivers/net/ethernet/intel/igc/igc_main.c | 34 +-
> drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 106 ++--
> .../net/ethernet/intel/ixgbevf/ixgbevf_main.c | 49 +-
> drivers/net/ethernet/mellanox/mlx4/main.c | 6 +-
> .../net/ethernet/mellanox/mlx5/core/main.c | 26 +-
> .../net/ethernet/mellanox/mlxsw/spectrum.c | 16 +-
> drivers/net/ethernet/micrel/ksz884x.c | 8 +-
> .../net/ethernet/mucse/rnpgbe/rnpgbe_main.c | 10 +-
> drivers/net/ethernet/natsemi/natsemi.c | 4 +-
> drivers/net/ethernet/netronome/nfp/nfp_main.c | 81 +--
> .../ethernet/netronome/nfp/nfp_netvf_main.c | 41 +-
> drivers/net/ethernet/qlogic/qede/qede_main.c | 20 +-
> drivers/net/ethernet/realtek/8139too.c | 52 +-
> drivers/net/ethernet/realtek/r8169_main.c | 8 +-
> drivers/net/ethernet/rocker/rocker_main.c | 4 +-
> drivers/net/ethernet/sis/sis190.c | 6 +-
> drivers/net/ethernet/sis/sis900.c | 10 +-
> drivers/net/ethernet/smsc/epic100.c | 18 +-
> drivers/net/ethernet/sun/cassini.c | 8 +-
> drivers/net/ethernet/sun/sungem.c | 26 +-
> drivers/net/ethernet/ti/tlan.c | 41 +-
> drivers/net/ethernet/wangxun/ngbe/ngbe_main.c | 26 +-
> .../net/ethernet/wangxun/ngbevf/ngbevf_main.c | 26 +-
> .../net/ethernet/wangxun/txgbe/txgbe_main.c | 18 +-
> .../ethernet/wangxun/txgbevf/txgbevf_main.c | 18 +-
> drivers/net/wan/farsync.c | 24 +-
> drivers/net/wan/pc300too.c | 14 +-
> drivers/net/wan/pci200syn.c | 6 +-
> drivers/net/wan/wanxl.c | 11 +-
> .../broadcom/brcm80211/brcmfmac/pcie.c | 17 +-
> drivers/net/wireless/intel/ipw2x00/ipw2200.c | 52 +-
> 69 files changed, 1308 insertions(+), 1101 deletions(-)
>
> diff --git a/drivers/net/arcnet/com20020-pci.c
> b/drivers/net/arcnet/com20020-pci.c
> index dbadda08dce2..6474c7be2992 100644
> --- a/drivers/net/arcnet/com20020-pci.c
> +++ b/drivers/net/arcnet/com20020-pci.c
> @@ -459,168 +459,88 @@ static struct com20020_pci_card_info
> card_info_eae_fb2 = {
>
> static const struct pci_device_id com20020pci_id_table[] = {
> {
...
> };
>
> MODULE_DEVICE_TABLE(pci, card_ids);
>
> base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
> --
> 2.47.3
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH] i40e: Fix i40e_debug() to use struct i40e_hw argument
From: Loktionov, Aleksandr @ 2026-04-29 9:20 UTC (permalink / raw)
To: Mohamed Khalfella, Nguyen, Anthony L, Kitszel, Przemyslaw,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260428181450.2622899-1-mkhalfella@purestorage.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Mohamed Khalfella
> Sent: Tuesday, April 28, 2026 8:15 PM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>; David S . Miller
> <davem@davemloft.net>; Eric Dumazet <edumazet@google.com>; Jakub
> Kicinski <kuba@kernel.org>; Paolo Abeni <pabeni@redhat.com>
> Cc: Mohamed Khalfella <mkhalfella@purestorage.com>; intel-wired-
> lan@lists.osuosl.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Subject: [Intel-wired-lan] [PATCH] i40e: Fix i40e_debug() to use
> struct i40e_hw argument
>
> i40e_debug() macro takes struct i40e_hw *h as first argument. But the
> macro body uses hw instead of h. This has been working so far because
> hw happen to be the name of the variable in the context where the
> marco is expanded. Fix the macro to use the passed argument.
>
> Signed-off-by: Mohamed Khalfella <mkhalfella@purestorage.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_debug.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_debug.h
> b/drivers/net/ethernet/intel/i40e/i40e_debug.h
> index e9871dfb32bd..01fd70db9086 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_debug.h
> +++ b/drivers/net/ethernet/intel/i40e/i40e_debug.h
> @@ -42,7 +42,7 @@ struct device *i40e_hw_to_dev(struct i40e_hw *hw);
> #define i40e_debug(h, m, s, ...) \
> do { \
> if (((m) & (h)->debug_mask)) \
> - dev_info(i40e_hw_to_dev(hw), s, ##__VA_ARGS__); \
> + dev_info(i40e_hw_to_dev(h), s, ##__VA_ARGS__); \
> } while (0)
>
> #endif /* _I40E_DEBUG_H_ */
> --
> 2.53.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH iwl-next 3/3] virtchnl, iavf, ice, i40e: add extended generic VF capability flags
From: Loktionov, Aleksandr @ 2026-04-29 9:21 UTC (permalink / raw)
To: Marcin Szycik, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Greenwalt, Paul, Keller, Jacob E,
Kitszel, Przemyslaw
In-Reply-To: <20260428143716.9653-4-marcin.szycik@linux.intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Marcin Szycik
> Sent: Tuesday, April 28, 2026 4:37 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Greenwalt, Paul
> <paul.greenwalt@intel.com>; Keller, Jacob E
> <jacob.e.keller@intel.com>; Marcin Szycik
> <marcin.szycik@linux.intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>
> Subject: [Intel-wired-lan] [PATCH iwl-next 3/3] virtchnl, iavf, ice,
> i40e: add extended generic VF capability flags
>
> VF capability flags in struct virtchnl_vf_resource::vf_cap_flags have
> all been used up, preventing new flags from being added. Note that
> despite not all bits being defined here, they are used by out-of-tree
> releases of Intel drivers, therefore cannot be taken.
>
> virtchnl message size and structure must remain unchanged to not break
> reverse compatibility, therefore the existing virtchnl structure
> cannot be extended with additional fields (e.g. flags2). vf_cap_flags
> type cannot be changed to a larger one for the same reason.
>
> Bit 2 of vf_cap_flags was reserved for exactly this case. Its presence
> in message initially sent from VF shall now signal that there are more
> capability flags to be parsed. If the PF driver acknowledges that via
> VIRTCHNL_OP_GET_VF_RESOURCES response, the VF will send a separate
> message: VIRTCHNL_OP_GET_VF_CAPS2, containing more capability flags.
> Note: this mechanism is similar for VIRTCHNL_OP_1588_PTP_GET_CAPS.
>
> The new message supports flexible size, so more flags can be added
> without any architectural changes. Care was taken to ensure that no
> out-of-bounds reads happen in case the bitmap is shorter in one of the
> drivers.
>
> The new message includes the original 32 bits too, for consistency and
> more straightforward parsing.
>
> Signed-off-by: Marcin Szycik <marcin.szycik@linux.intel.com>
> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
> Reviewed-by: Jacob Keller <jacob.e.keller@intel.com>
> ---
> drivers/net/ethernet/intel/iavf/iavf.h | 19 ++-
> .../net/ethernet/intel/ice/virt/virtchnl.h | 2 +
> include/linux/intel/virtchnl.h | 55 ++++++-
> .../ethernet/intel/i40e/i40e_virtchnl_pf.c | 84 +++++++++++
> drivers/net/ethernet/intel/iavf/iavf_main.c | 60 ++++++++
> .../net/ethernet/intel/iavf/iavf_virtchnl.c | 138
> +++++++++++++++++-
> .../net/ethernet/intel/ice/virt/allowlist.c | 6 +
> .../net/ethernet/intel/ice/virt/virtchnl.c | 86 +++++++++++
> 8 files changed, 444 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/iavf/iavf.h
> b/drivers/net/ethernet/intel/iavf/iavf.h
> index 64576cba3a01..5d812b0a52a3 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf.h
> +++ b/drivers/net/ethernet/intel/iavf/iavf.h
> @@ -343,6 +343,7 @@ struct iavf_adapter {
> #define IAVF_FLAG_AQ_GET_SUPPORTED_RXDIDS BIT_ULL(42)
> #define IAVF_FLAG_AQ_GET_PTP_CAPS BIT_ULL(43)
> #define IAVF_FLAG_AQ_SEND_PTP_CMD BIT_ULL(44)
...
> case VIRTCHNL_OP_UNKNOWN:
> default:
> dev_err(dev, "Unsupported opcode %d from VF %d\n",
> v_opcode,
> --
> 2.49.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* Re: [PATCH net v2 2/4] net: macb: drop in-flight Tx SKBs on close
From: Théo Lebrun @ 2026-04-29 9:26 UTC (permalink / raw)
To: Nicolai Buchwitz
Cc: Nicolas Ferre, Claudiu Beznea, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Haavard Skinnemoen,
Jeff Garzik, Paolo Valerio, Conor Dooley, netdev, linux-kernel,
Vladimir Kondratiev, Gregory CLEMENT, Benoît Monin,
Tawfik Bayouk, Thomas Petazzoni, Maxime Chevallier, stable
In-Reply-To: <75229fab491465e06a98ee580a51f0b4@tipi-net.de>
Hello Nicolai,
On Tue Apr 28, 2026 at 11:30 PM CEST, Nicolai Buchwitz wrote:
> On 28.4.2026 18:32, Théo Lebrun wrote:
>> The MACB driver has since forever leaked the outgoing SKBs that
>> have not yet been marked as completed. They live in queue->tx_skb
>> which gets freed without remorse nor checking.
>>
>> macb_free_consistent() gets called in a few codepaths, but only
>> close will trigger the added expressions. In macb_open() and
>> macb_alloc_consistent() failure cases, tx_skb just got allocated
>> and is empty.
>>
>> Use the new macb_tx_unmap() prototype to report our error as
>> SKB_DROP_REASON_NOT_SPECIFIED rather than SKB_CONSUMED which makes it
>> sound like no error occurred. Equivalent to dev_kfree_skb_any().
>>
>> Fixes: 89e5785fc8a6 ("[PATCH] Atmel MACB ethernet driver")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Théo Lebrun <theo.lebrun@bootlin.com>
>> ---
>> drivers/net/ethernet/cadence/macb_main.c | 22 ++++++++++++++++++++--
>> 1 file changed, 20 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/ethernet/cadence/macb_main.c
>> b/drivers/net/ethernet/cadence/macb_main.c
>> index 9caae1ef52b1..5a2500bd59a6 100644
>> --- a/drivers/net/ethernet/cadence/macb_main.c
>> +++ b/drivers/net/ethernet/cadence/macb_main.c
>> @@ -2678,8 +2678,26 @@ static void macb_free_consistent(struct macb
>> *bp)
>> dma_free_coherent(dev, size, bp->queues[0].rx_ring,
>> bp->queues[0].rx_ring_dma);
>>
>> for (q = 0, queue = bp->queues; q < bp->num_queues; ++q, ++queue) {
>> - kfree(queue->tx_skb);
>> - queue->tx_skb = NULL;
>> + if (queue->tx_skb) {
>> + unsigned int dropped = 0, tail;
>> +
>> + for (tail = queue->tx_tail; tail != queue->tx_head;
>> + tail++) {
>> + if (macb_tx_skb(queue, tail)->skb)
>> + dropped++;
>> + macb_tx_unmap(bp, macb_tx_skb(queue, tail), 0,
>> + SKB_DROP_REASON_NOT_SPECIFIED);
>> + }
>
> Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Thanks for the review!
We are quite a few caring about MACB which is nice.
> Side note, not blocking: macb_close() doesn't cancel tx_error_task,
> so the workqueue handler can race with this loop on tx_skb[]. The
> exposure is pre-existing, but maybe worth a follow-up adding
> cancel_work_sync() between napi_disable() and macb_free_consistent().
Yes, noticed that while working on the context swapping series [0].
The goal here is to improve MACB piecewise, so I won't take that on in
the current series.
[0]: https://lore.kernel.org/all/90f843aa3940bdbabadddce27314c1f1@tipi-net.de/t/#mda18f759c27a4d833084b23605463994632d97e3
(and the two replies)
Thanks,
--
Théo Lebrun, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 5/9] arm64: dts: qcom: arduino-imola: Get WiFi MAC from NVMEM
From: Konrad Dybcio @ 2026-04-29 9:30 UTC (permalink / raw)
To: Loic Poulain, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Jens Axboe,
Johannes Berg, Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel
In-Reply-To: <20260428-block-as-nvmem-v1-5-6ad23e75190a@oss.qualcomm.com>
On 4/28/26 4:23 PM, Loic Poulain wrote:
> On Arduino Uno-Q, the WiFi MAC address is stored in the eMMC
> boot1 partition. Point to the appropriate NVMEM cell to
> retrieve it.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [PATCH 4/9] dt-bindings: net: wireless: qcom,ath10k: Add NVMEM MAC address cell
From: Konrad Dybcio @ 2026-04-29 9:31 UTC (permalink / raw)
To: Loic Poulain, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Jens Axboe,
Johannes Berg, Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel
In-Reply-To: <20260428-block-as-nvmem-v1-4-6ad23e75190a@oss.qualcomm.com>
On 4/28/26 4:23 PM, Loic Poulain wrote:
> Add support for an NVMEM cell provider with the standard "mac-address"
> cell name. This allows the ath10k device to retrieve its MAC address
> from non-volatile storage such as an EEPROM or an eMMC partition.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
> .../devicetree/bindings/net/wireless/qcom,ath10k.yaml | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> index c21d66c7cd558ab792524be9afec8b79272d1c87..7155d8b15cc145c3a7d703db0c9c3e056a54c07e 100644
> --- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> +++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.yaml
> @@ -92,6 +92,16 @@ properties:
>
> ieee80211-freq-limit: true
>
> + nvmem-cells:
> + maxItems: 1
> + description:
> + Nvmem data cell that contains a 6 byte MAC address with the most
> + significant byte first (big-endian).
> +
> + nvmem-cell-names:
> + items:
> + - const: mac-address
This can just be "const: mac-address" if you don't expect any additional
entries
Konrad
^ permalink raw reply
* Re: [PATCH 9/9] arm64: dts: qcom: arduino-imola: Get Bluetooth BD address from NVMEM
From: Konrad Dybcio @ 2026-04-29 9:32 UTC (permalink / raw)
To: Loic Poulain, Ulf Hansson, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bjorn Andersson, Konrad Dybcio, Jens Axboe,
Johannes Berg, Jeff Johnson, Bartosz Golaszewski, Marcel Holtmann,
Luiz Augusto von Dentz, Balakrishna Godavarthi, Rocky Liao,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: linux-mmc, devicetree, linux-kernel, linux-arm-msm, linux-block,
linux-wireless, ath10k, linux-bluetooth, netdev, daniel
In-Reply-To: <20260428-block-as-nvmem-v1-9-6ad23e75190a@oss.qualcomm.com>
On 4/28/26 4:23 PM, Loic Poulain wrote:
> On Arduino Uno-Q, the Bluetooth Device address is stored in the eMMC
> boot1 partition. Point to the appropriate NVMEM cell to retrieve it.
>
> Signed-off-by: Loic Poulain <loic.poulain@oss.qualcomm.com>
> ---
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Konrad
^ permalink raw reply
* Re: [bug report] Potential refcounting
From: Ginger @ 2026-04-29 10:13 UTC (permalink / raw)
To: Tariq Toukan; +Cc: netdev, linux-rdma, ttoukan.linux
In-Reply-To: <345650f0-6da6-447c-9b27-0bbefca0558f@nvidia.com>
Hi Tariq,
Thank you for your prompt and detailed response. I agree with your
point that calling refcount_dec_and_test() is safe.
However, the major concern of the original report is that whether
simply calling 'refcount_inc()' is safe in 'mlx4_add_cq_to_tasklet()':
T0:
if during a tasklet callback calling 'mlx4_cq_tasklet_cb', a destroy
verb arrives, which eventually leads to 'mlx4_cq_free()'. Both
functions can decrement the 'cq->refcount' and potentially enable
cq->free.
T1:
irq fires --> mlx4_cq_completion --> mlx4_add_cq_to_tasklet -->
refcount_inc(). Here, the refcount increment does not check whether it
has been zeroed in T0.
Side note: to see if T1 (i.e., IRQ) can fire, I checked the calling
path to 'mlx4_cq_free' and only 'synchronize_irq()' is seen, but not
'disable_irq()'. It means that T1 may still happen after T0 calls
'mlx4_cq_free()'.
Is the above race possible? IMHO, perhaps it would better to change
'refcount_inc()' to something like 'refcount_inc_not_zero()' if the
race may happen.
Best regards,
Ginger
On Wed, Apr 29, 2026 at 4:36 PM Tariq Toukan <tariqt@nvidia.com> wrote:
>
>
>
> On 27/04/2026 5:07, Ginger wrote:
> > Dear Linux kernel maintainers,
> >
> > My research-based static analyzer found a potential
> > refcounting/atomicity bug within the
> > 'drivers/net/ethernet/mellanox/mlx4' subsystem, more specifically, in
> > 'drivers/net/ethernet/mellanox/mlx4/cq.c'.
> >
> > Kernel version: long-term kernel v6.18.9
> >
> > Potential concurrent triggering executions:
> > T0:
> > mlx4_cq_tasklet_cb
> > --> if (refcount_dec_and_test(&mcq->refcount))
> > --> complete(&mcq->free)
> >
> > T1:
> > mlx4_cq_completion
> > --> cq->comp(cq);
> > --> mlx4_add_cq_to_tasklet(struct mlx4_cq *cq)
> > --> spin_lock_irqsave(&tasklet_ctx->lock, flags);
> > --> refcount_inc(&cq->refcount);
> > --> spin_unlock_irqrestore(&tasklet_ctx->lock, flags);
> >
> > In T1, the refcounting increment on 'cq->refcount)', although within
> > the protection range of the 'tasklet_ctx->locl', is not synchronized
> > against T0 because 'refcount_inc()' does not check whether the
> > refcount has reached zero in T0. This case is potentially problematic
> > because T0 decrements he 'mcq->refcount' and can enable the
> > 'mlx4_cq_free()' to proceed.
> >
> > Thank you for your time and consideration.
> >
> > Best regards,
> > Ginger
> >
>
> Hi,
>
> Thanks for your report.
>
> IMO the described race is impossible.
>
> CQs that work with mlx4_add_cq_to_tasklet as their comp() callback (i.e.
> T1) are added to the relevant list only after refcount is incremented.
>
> Hence, if a CQ exists in the list in T0, it necessarily means that
> refcount is already elevated, and calling refcount_dec_and_test is safe.
>
> Regards,
> Tariq
^ permalink raw reply
* [PATCH net v5 0/4] Fix i40e/ice/iavf VF bonding after netdev lock changes
From: Jose Ignacio Tornos Martinez @ 2026-04-29 10:24 UTC (permalink / raw)
To: netdev
Cc: intel-wired-lan, przemyslaw.kitszel, aleksandr.loktionov,
jacob.e.keller, horms, jesse.brandeburg, anthony.l.nguyen, davem,
edumazet, kuba, pabeni, Jose Ignacio Tornos Martinez
This series fixes VF bonding failures introduced by commit ad7c7b2172c3
("net: hold netdev instance lock during sysfs operations").
When adding VFs to a bond immediately after setting trust mode, MAC
address changes fail with -EAGAIN, preventing bonding setup. This
affects both i40e (700-series) and ice (800-series) Intel NICs.
The core issue is lock contention: iavf_set_mac() is now called with the
netdev lock held and waits for MAC change completion while holding it.
However, both the watchdog task that sends the request and the adminq_task
that processes PF responses also need this lock, creating a deadlock where
neither can run, causing timeouts.
Additionally, setting VF trust triggers an unnecessary ~10 second VF reset
in i40e driver that delays bonding setup, even though filter
synchronization happens naturally during normal VF operation. For ice
driver, the delay is not so big, but in the same way the operation is not
necessary.
This series:
1. Adds safety guard to prevent MAC changes during reset or early
initialization (before VF is ready)
2. Eliminates unnecessary VF reset when setting trust in i40e (reset only
if revoking trust and VF has advanced features configured).
3. Fixes lock contention by polling admin queue synchronously
4. Eliminates unnecessary VF reset when setting trust in ice, (reset only
if revoking trust and VF has advanced features configured).
The key fix (patch 3/4) implements a synchronous MAC change operation
similar to the approach used for ndo_change_mtu deadlock fix:
https://lore.kernel.org/intel-wired-lan/20260211191855.1532226-1-poros@redhat.com/
Instead of scheduling work and waiting, it:
- Sends the virtchnl message directly (not via watchdog)
- Polls the admin queue hardware directly for responses
- Processes all messages inline (including non-MAC messages)
- Returns when complete or times out
This allows the operation to complete synchronously while holding
netdev_lock, without relying on watchdog or adminq_task.
The function can sleep for up to 2.5 seconds polling hardware, but this
is acceptable since netdev_lock is per-device and only serializes
operations on the same interface.
Testing shows VF bonding now works reliably in ~5 seconds vs 15+ seconds
before (i40e), without timeouts or errors (i40e and ice).
Tested on Intel 700-series (i40e) and 800-series (ice) dual-port NICs
with iavf driver.
Thanks to Jan Tluka <jtluka@redhat.com> and Yuying Ma <yuma@redhat.com> for
reporting the issues.
Jose Ignacio Tornos Martinez (4):
iavf: return EBUSY if reset in progress or not ready during MAC change
i40e: skip unnecessary VF reset when setting trust
iavf: send MAC change request synchronously
ice: skip unnecessary VF reset when setting trust
---
v5:
- No changes to patch 1 from v4
- For the new functions or with changes in the prototypes, kdoc should end
with '*/' not '**/', patch 2, 3 and 4
- For patch 2 and patch 4, after the comments from AI review (sashiko.dev)
from Simon Horman, adopt a conservative approach checking multiple
conditions before skipping the reset
- Complete patch 3 with the comments from Przemek Kitszel and AI review
from Simon Horman.
v4: https://lore.kernel.org/all/20260423130405.139568-1-jtornosm@redhat.com/
drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c | 38 ++++++++++++++++++++++++++++----------
drivers/net/ethernet/intel/iavf/iavf.h | 10 ++++++++--
drivers/net/ethernet/intel/iavf/iavf_main.c | 74 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------
drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 100 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++----------
drivers/net/ethernet/intel/ice/ice_sriov.c | 33 +++++++++++++++++++++++++++++----
5 files changed, 211 insertions(+), 44 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH net v5 1/4] iavf: return EBUSY if reset in progress or not ready during MAC change
From: Jose Ignacio Tornos Martinez @ 2026-04-29 10:24 UTC (permalink / raw)
To: netdev
Cc: intel-wired-lan, przemyslaw.kitszel, aleksandr.loktionov,
jacob.e.keller, horms, jesse.brandeburg, anthony.l.nguyen, davem,
edumazet, kuba, pabeni, Jose Ignacio Tornos Martinez
In-Reply-To: <20260429102426.210750-1-jtornosm@redhat.com>
When a MAC address change is requested while the VF is resetting or still
initializing, return -EBUSY immediately instead of attempting the
operation.
Additionally, during early initialization states (before __IAVF_DOWN),
the PF may be slow to respond to MAC change requests, causing long
delays. Only allow MAC changes once the VF reaches __IAVF_DOWN state or
later, when the watchdog is running and the VF is ready for operations.
After commit ad7c7b2172c3 ("net: hold netdev instance lock
during sysfs operations"), MAC changes are called with the netdev lock
held, so we should not wait with the lock held during reset or
initialization. This allows the caller to retry or handle the busy state
appropriately without blocking other operations.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
---
drivers/net/ethernet/intel/iavf/iavf_main.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
index dad001abc908..67aa14350b1b 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_main.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
@@ -1060,6 +1060,9 @@ static int iavf_set_mac(struct net_device *netdev, void *p)
struct sockaddr *addr = p;
int ret;
+ if (iavf_is_reset_in_progress(adapter) || adapter->state < __IAVF_DOWN)
+ return -EBUSY;
+
if (!is_valid_ether_addr(addr->sa_data))
return -EADDRNOTAVAIL;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 net-next] net/intel: Replace manual array size calculation with ARRAY_SIZE
From: Dan Carpenter @ 2026-04-29 10:24 UTC (permalink / raw)
To: Przemek Kitszel
Cc: Jakub Raczynski, netdev, kuba, intel-wired-lan, linux-kernel,
kernel-janitors
In-Reply-To: <b0a706e1-2494-40b4-836f-f5d32c6b0fef@intel.com>
On Wed, Apr 29, 2026 at 11:01:46AM +0200, Przemek Kitszel wrote:
> F: Documentation/networking/device_drivers/ethernet/intel/
> F: drivers/net/ethernet/intel/
> F: drivers/net/ethernet/intel/*/
> F: include/linux/avf/virtchnl.h
> F: include/linux/net/intel/*/
>
Fine. Thanks. I can add this.
> Perhaps instead of you managing your script, and everybody else doing
> the same, there could be some extension added to MAINTAINERS file to
> encode the prefix?
>
> In our case, the prefix itself is a message for net maintainers:
> iwl or iwl-next means the patch will go first via our tree, and be sent
> later as a PR for net/net-next.
>
> Without the prefix it requires guessing what was the submitter intent.
We don't have any intent. So long as it gets merged who cares how it
happens?
> Most patches that go through IWL receive additional round of testing on
> real HW too, thanks to our VAL.
> Patches that go straight to net are just merged faster.
> As intel ethernet maintainer, I want our code tested more, instead of
> merged faster (in most cases).
All of this scripting could be done on your end. No matter how many
dozens of people you educate to add a different prefix it's always
going to be less reliable than just scripting it on your side.
Anyway, here is the relevant bit from my script. The other subsystem
that requires these is BPF but I only send bug reports for BPF issues.
You also need to do a git fetch of all the trees with subsystem rules.
regards,
dan carpenter
# Is this networking?
if grep -q netdev $MAIL_FILE && ! grep -q wireless $MAIL_FILE ; then
if [ "$FIXES_COMMIT" != "" ] ; then
if git merge-base --is-ancestor $FIXES_COMMIT net/main ; then
TREE="net"
elif git merge-base --is-ancestor $FIXES_COMMIT net-next/main ; then
TREE="net-next"
else
TREE="net-other"
fi
else
TREE="net-next"
fi
fi
# Is this Intel Wireless
if grep -q -w /iwlwifi/ $MAIL_FILE ; then
if [ "$FIXES_COMMIT" != "" ] ; then
if git merge-base --is-ancestor $FIXES_COMMIT iwlwifi/fixes ; then
TREE="iwlwifi"
elif git merge-base --is-ancestor $FIXES_COMMIT iwlwifi/next ; then
TREE="iwlwifi-next"
else
TREE="iwlwifi-other"
fi
else
TREE="iwlwifi-next"
fi
fi
# Otherwise if the commit is only required in next then put [PATCH next]
# in the subject.
if [ "$TREE" == "" ] ; then
if [ "$FIXES_COMMIT" != "" ] ; then
if ! git merge-base --is-ancestor $FIXES_COMMIT origin/master ; then
TREE="next"
fi
fi
fi
^ permalink raw reply
* [PATCH net v5 2/4] i40e: skip unnecessary VF reset when setting trust
From: Jose Ignacio Tornos Martinez @ 2026-04-29 10:24 UTC (permalink / raw)
To: netdev
Cc: intel-wired-lan, przemyslaw.kitszel, aleksandr.loktionov,
jacob.e.keller, horms, jesse.brandeburg, anthony.l.nguyen, davem,
edumazet, kuba, pabeni, Jose Ignacio Tornos Martinez
In-Reply-To: <20260429102426.210750-1-jtornosm@redhat.com>
The current implementation triggers a VF reset when changing the trust
setting, causing a ~10 second delay during bonding setup.
In all the cases, the reset causes a ~10 second delay during which:
- VF must reinitialize completely
- Any in-progress operations (like bonding enslave) fail with timeouts
- VF is unavailable
When granting trust, no reset is needed - we can just set the capability
flag to allow privileged operations.
When revoking trust, we only need to reset (conservative approach) if
the VF has actually configured advanced features that require cleanup
(ADQ/cloud filters, promiscuous mode). For VFs in a clean state, we can
safely change the trust setting without the disruptive reset.
When we don't reset, we manually handle capability flag via helper
function, eliminating the delay.
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v5: kdoc should end with '*/' not '**/' (new function)
Address AI review (sashiko.dev) from Simon Horman:
- Adopt a conservative approach checking multiple conditions before
skipping reset: ADQ, cloud filters, promiscuous mode
- Simplify helper function to only handle capability flag
v4: https://lore.kernel.org/all/20260423130405.139568-3-jtornosm@redhat.com/
.../ethernet/intel/i40e/i40e_virtchnl_pf.c | 38 ++++++++++++++-----
1 file changed, 28 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
index a26c3d47ec15..0cc434b26eb8 100644
--- a/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
+++ b/drivers/net/ethernet/intel/i40e/i40e_virtchnl_pf.c
@@ -4943,6 +4943,23 @@ int i40e_ndo_set_vf_spoofchk(struct net_device *netdev, int vf_id, bool enable)
return ret;
}
+/**
+ * i40e_setup_vf_trust - Enable/disable VF trust mode without reset
+ * @vf: VF to configure
+ * @setting: trust setting
+ *
+ * Update VF flags when changing trust without performing a VF reset.
+ * This is only called when it's safe to skip the reset (VF has no advanced
+ * features configured that need cleanup).
+ */
+static void i40e_setup_vf_trust(struct i40e_vf *vf, bool setting)
+{
+ if (setting)
+ set_bit(I40E_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps);
+ else
+ clear_bit(I40E_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps);
+}
+
/**
* i40e_ndo_set_vf_trust
* @netdev: network interface device structure of the pf
@@ -4987,19 +5004,20 @@ int i40e_ndo_set_vf_trust(struct net_device *netdev, int vf_id, bool setting)
set_bit(__I40E_MACVLAN_SYNC_PENDING, pf->state);
pf->vsi[vf->lan_vsi_idx]->flags |= I40E_VSI_FLAG_FILTER_CHANGED;
- i40e_vc_reset_vf(vf, true);
+ /* Reset only if revoking trust and VF has advanced features configured */
+ if (!setting &&
+ (vf->adq_enabled || vf->num_cloud_filters > 0 ||
+ test_bit(I40E_VF_STATE_UC_PROMISC, &vf->vf_states) ||
+ test_bit(I40E_VF_STATE_MC_PROMISC, &vf->vf_states))) {
+ i40e_vc_reset_vf(vf, true);
+ i40e_del_all_cloud_filters(vf);
+ } else {
+ i40e_setup_vf_trust(vf, setting);
+ }
+
dev_info(&pf->pdev->dev, "VF %u is now %strusted\n",
vf_id, setting ? "" : "un");
- if (vf->adq_enabled) {
- if (!vf->trusted) {
- dev_info(&pf->pdev->dev,
- "VF %u no longer Trusted, deleting all cloud filters\n",
- vf_id);
- i40e_del_all_cloud_filters(vf);
- }
- }
-
out:
clear_bit(__I40E_VIRTCHNL_OP_PENDING, pf->state);
return ret;
--
2.53.0
^ permalink raw reply related
* [PATCH net v5 3/4] iavf: send MAC change request synchronously
From: Jose Ignacio Tornos Martinez @ 2026-04-29 10:24 UTC (permalink / raw)
To: netdev
Cc: intel-wired-lan, przemyslaw.kitszel, aleksandr.loktionov,
jacob.e.keller, horms, jesse.brandeburg, anthony.l.nguyen, davem,
edumazet, kuba, pabeni, Jose Ignacio Tornos Martinez, stable
In-Reply-To: <20260429102426.210750-1-jtornosm@redhat.com>
After commit ad7c7b2172c3 ("net: hold netdev instance lock during sysfs
operations"), iavf_set_mac() is called with the netdev instance lock
already held.
The function queues a MAC address change request via
iavf_replace_primary_mac() and then waits for completion. However, in
the current flow, the actual virtchnl message is sent by the watchdog
task, which also needs to acquire the netdev lock to run. Additionally,
the adminq_task which processes virtchnl responses also needs the netdev
lock.
This creates a deadlock scenario:
1. iavf_set_mac() holds netdev lock and waits for MAC change
2. Watchdog needs netdev lock to send the request -> blocked
3. Even if request is sent, adminq_task needs netdev lock to process
PF response -> blocked
4. MAC change times out after 2.5 seconds
5. iavf_set_mac() returns -EAGAIN
This particularly affects VFs during bonding setup when multiple VFs are
enslaved in quick succession.
Fix by implementing a synchronous MAC change operation similar to the
approach used in commit fdadbf6e84c4 ("iavf: fix incorrect reset handling
in callbacks").
The solution:
1. Send the virtchnl ADD_ETH_ADDR message directly (not via watchdog)
2. Poll the admin queue hardware directly for responses
3. Process all received messages (including non-MAC messages)
4. Return when MAC change completes or times out
A new generic function iavf_poll_virtchnl_response() is introduced that
can be reused for any future synchronous virtchnl operations. It takes a
callback to check completion, allowing flexible condition checking.
This allows the operation to complete synchronously while holding
netdev_lock, without relying on watchdog or adminq_task. The function
can sleep for up to 2.5 seconds polling hardware, but this is acceptable
since netdev_lock is per-device and only serializes operations on the
same interface.
To support this, change iavf_add_ether_addrs() to return an error code
instead of void, allowing callers to detect failures. Additionally,
export iavf_mac_add_reject() to enable proper rollback on local failures
(timeouts, send errors) - PF rejections are already handled automatically
by iavf_virtchnl_completion().
Remove vc_waitqueue entirely because iavf_set_mac was the only waiter on
this waitqueue and after the changes it is not needed.
Fixes: ad7c7b2172c3 ("net: hold netdev instance lock during sysfs operations")
cc: stable@vger.kernel.org
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v5: Address the comments from Przemek Kitszel:
- Add note in commit message about vc_waitqueue removal.
- Change kdoc to use "Return:" instead of "Returns"
- kdoc should end with '*/' not '**/' (new functions or with changes in the
prototypes)
- Sort lines from longest to shortest (iavf_poll_virtchnl_response)
- Avoid "sleep then check time" (iavf_poll_virtchnl_response)
Address AI review (sashiko.dev) from Simon Horman:
- Restore adapter->hw.mac.addr on local failure (complete rollback
in iavf_set_mac)
- Remove timeout current_op clearing to prevent overlapping command
race, the status can be controlled from outside and better to not
corrupt it (iavf_poll_virtchnl_response) (as in v3).
v4: https://lore.kernel.org/all/20260423130405.139568-4-jtornosm@redhat.com/
drivers/net/ethernet/intel/iavf/iavf.h | 10 +-
drivers/net/ethernet/intel/iavf/iavf_main.c | 71 +++++++++----
.../net/ethernet/intel/iavf/iavf_virtchnl.c | 100 ++++++++++++++++--
3 files changed, 151 insertions(+), 30 deletions(-)
diff --git a/drivers/net/ethernet/intel/iavf/iavf.h b/drivers/net/ethernet/intel/iavf/iavf.h
index e9fb0a0919e3..78fa3df06e11 100644
--- a/drivers/net/ethernet/intel/iavf/iavf.h
+++ b/drivers/net/ethernet/intel/iavf/iavf.h
@@ -260,7 +260,6 @@ struct iavf_adapter {
struct work_struct adminq_task;
struct work_struct finish_config;
wait_queue_head_t down_waitqueue;
- wait_queue_head_t vc_waitqueue;
struct iavf_q_vector *q_vectors;
struct list_head vlan_filter_list;
int num_vlan_filters;
@@ -589,8 +588,9 @@ void iavf_configure_queues(struct iavf_adapter *adapter);
void iavf_enable_queues(struct iavf_adapter *adapter);
void iavf_disable_queues(struct iavf_adapter *adapter);
void iavf_map_queues(struct iavf_adapter *adapter);
-void iavf_add_ether_addrs(struct iavf_adapter *adapter);
+int iavf_add_ether_addrs(struct iavf_adapter *adapter);
void iavf_del_ether_addrs(struct iavf_adapter *adapter);
+void iavf_mac_add_reject(struct iavf_adapter *adapter);
void iavf_add_vlans(struct iavf_adapter *adapter);
void iavf_del_vlans(struct iavf_adapter *adapter);
void iavf_set_promiscuous(struct iavf_adapter *adapter);
@@ -607,6 +607,12 @@ void iavf_disable_vlan_stripping(struct iavf_adapter *adapter);
void iavf_virtchnl_completion(struct iavf_adapter *adapter,
enum virtchnl_ops v_opcode,
enum iavf_status v_retval, u8 *msg, u16 msglen);
+int iavf_poll_virtchnl_response(struct iavf_adapter *adapter,
+ bool (*condition)(struct iavf_adapter *adapter,
+ const void *data,
+ enum virtchnl_ops v_op),
+ const void *cond_data,
+ unsigned int timeout_ms);
int iavf_config_rss(struct iavf_adapter *adapter);
void iavf_cfg_queues_bw(struct iavf_adapter *adapter);
void iavf_cfg_queues_quanta_size(struct iavf_adapter *adapter);
diff --git a/drivers/net/ethernet/intel/iavf/iavf_main.c b/drivers/net/ethernet/intel/iavf/iavf_main.c
index 67aa14350b1b..dcf5494f72de 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_main.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_main.c
@@ -1047,6 +1047,48 @@ static bool iavf_is_mac_set_handled(struct net_device *netdev,
return ret;
}
+/**
+ * iavf_mac_change_done - Check if MAC change completed
+ * @adapter: board private structure
+ * @data: MAC address being checked (as const void *)
+ * @v_op: virtchnl opcode from processed message
+ *
+ * Callback for iavf_poll_virtchnl_response() to check if MAC change completed.
+ *
+ * Return: true if MAC change completed, false otherwise
+ */
+static bool iavf_mac_change_done(struct iavf_adapter *adapter,
+ const void *data, enum virtchnl_ops v_op)
+{
+ const u8 *addr = data;
+
+ return iavf_is_mac_set_handled(adapter->netdev, addr);
+}
+
+/**
+ * iavf_set_mac_sync - Synchronously change MAC address
+ * @adapter: board private structure
+ * @addr: MAC address to set
+ *
+ * Send MAC change request to PF and poll admin queue for response.
+ * Caller must hold netdev_lock. This can sleep for up to 2.5 seconds.
+ *
+ * Return: 0 on success, negative on failure
+ */
+static int iavf_set_mac_sync(struct iavf_adapter *adapter, const u8 *addr)
+{
+ int ret;
+
+ netdev_assert_locked(adapter->netdev);
+
+ ret = iavf_add_ether_addrs(adapter);
+ if (ret)
+ return ret;
+
+ return iavf_poll_virtchnl_response(adapter, iavf_mac_change_done,
+ addr, 2500);
+}
+
/**
* iavf_set_mac - NDO callback to set port MAC address
* @netdev: network interface device structure
@@ -1067,25 +1109,21 @@ static int iavf_set_mac(struct net_device *netdev, void *p)
return -EADDRNOTAVAIL;
ret = iavf_replace_primary_mac(adapter, addr->sa_data);
-
if (ret)
return ret;
- ret = wait_event_interruptible_timeout(adapter->vc_waitqueue,
- iavf_is_mac_set_handled(netdev, addr->sa_data),
- msecs_to_jiffies(2500));
-
- /* If ret < 0 then it means wait was interrupted.
- * If ret == 0 then it means we got a timeout.
- * else it means we got response for set MAC from PF,
- * check if netdev MAC was updated to requested MAC,
- * if yes then set MAC succeeded otherwise it failed return -EACCES
- */
- if (ret < 0)
+ ret = iavf_set_mac_sync(adapter, addr->sa_data);
+ if (ret) {
+ /* Rollback for local failures (timeout, send error, -EBUSY).
+ * Note: If PF rejects the request (sends error response),
+ * iavf_virtchnl_completion() automatically calls
+ * iavf_mac_add_reject(), ret=0, and this is not executed.
+ * Only local failures (no PF response received) need manual rollback.
+ */
+ iavf_mac_add_reject(adapter);
+ ether_addr_copy(adapter->hw.mac.addr, netdev->dev_addr);
return ret;
-
- if (!ret)
- return -EAGAIN;
+ }
if (!ether_addr_equal(netdev->dev_addr, addr->sa_data))
return -EACCES;
@@ -5415,9 +5453,6 @@ static int iavf_probe(struct pci_dev *pdev, const struct pci_device_id *ent)
/* Setup the wait queue for indicating transition to down status */
init_waitqueue_head(&adapter->down_waitqueue);
- /* Setup the wait queue for indicating virtchannel events */
- init_waitqueue_head(&adapter->vc_waitqueue);
-
INIT_LIST_HEAD(&adapter->ptp.aq_cmds);
init_waitqueue_head(&adapter->ptp.phc_time_waitqueue);
mutex_init(&adapter->ptp.aq_cmd_lock);
diff --git a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
index a52c100dcbc5..fbd3c1a15039 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
@@ -2,6 +2,7 @@
/* Copyright(c) 2013 - 2018 Intel Corporation. */
#include <linux/net/intel/libie/rx.h>
+#include <net/netdev_lock.h>
#include "iavf.h"
#include "iavf_ptp.h"
@@ -555,20 +556,23 @@ iavf_set_mac_addr_type(struct virtchnl_ether_addr *virtchnl_ether_addr,
* @adapter: adapter structure
*
* Request that the PF add one or more addresses to our filters.
- **/
-void iavf_add_ether_addrs(struct iavf_adapter *adapter)
+ *
+ * Return: 0 on success, negative on failure
+ */
+int iavf_add_ether_addrs(struct iavf_adapter *adapter)
{
struct virtchnl_ether_addr_list *veal;
struct iavf_mac_filter *f;
int i = 0, count = 0;
bool more = false;
size_t len;
+ int ret;
if (adapter->current_op != VIRTCHNL_OP_UNKNOWN) {
/* bail because we already have a command pending */
dev_err(&adapter->pdev->dev, "Cannot add filters, command %d pending\n",
adapter->current_op);
- return;
+ return -EBUSY;
}
spin_lock_bh(&adapter->mac_vlan_list_lock);
@@ -580,7 +584,7 @@ void iavf_add_ether_addrs(struct iavf_adapter *adapter)
if (!count) {
adapter->aq_required &= ~IAVF_FLAG_AQ_ADD_MAC_FILTER;
spin_unlock_bh(&adapter->mac_vlan_list_lock);
- return;
+ return 0;
}
adapter->current_op = VIRTCHNL_OP_ADD_ETH_ADDR;
@@ -594,8 +598,9 @@ void iavf_add_ether_addrs(struct iavf_adapter *adapter)
veal = kzalloc(len, GFP_ATOMIC);
if (!veal) {
+ adapter->current_op = VIRTCHNL_OP_UNKNOWN;
spin_unlock_bh(&adapter->mac_vlan_list_lock);
- return;
+ return -ENOMEM;
}
veal->vsi_id = adapter->vsi_res->vsi_id;
@@ -615,8 +620,15 @@ void iavf_add_ether_addrs(struct iavf_adapter *adapter)
spin_unlock_bh(&adapter->mac_vlan_list_lock);
- iavf_send_pf_msg(adapter, VIRTCHNL_OP_ADD_ETH_ADDR, (u8 *)veal, len);
+ ret = iavf_send_pf_msg(adapter, VIRTCHNL_OP_ADD_ETH_ADDR, (u8 *)veal, len);
kfree(veal);
+ if (ret) {
+ dev_err(&adapter->pdev->dev,
+ "Unable to send ADD_ETH_ADDR message to PF, error %d\n", ret);
+ adapter->current_op = VIRTCHNL_OP_UNKNOWN;
+ }
+
+ return ret;
}
/**
@@ -712,8 +724,8 @@ static void iavf_mac_add_ok(struct iavf_adapter *adapter)
* @adapter: adapter structure
*
* Remove filters from list based on PF response.
- **/
-static void iavf_mac_add_reject(struct iavf_adapter *adapter)
+ */
+void iavf_mac_add_reject(struct iavf_adapter *adapter)
{
struct net_device *netdev = adapter->netdev;
struct iavf_mac_filter *f, *ftmp;
@@ -2389,7 +2401,6 @@ void iavf_virtchnl_completion(struct iavf_adapter *adapter,
iavf_mac_add_reject(adapter);
/* restore administratively set MAC address */
ether_addr_copy(adapter->hw.mac.addr, netdev->dev_addr);
- wake_up(&adapter->vc_waitqueue);
break;
case VIRTCHNL_OP_DEL_VLAN:
dev_err(&adapter->pdev->dev, "Failed to delete VLAN filter, error %s\n",
@@ -2586,7 +2597,6 @@ void iavf_virtchnl_completion(struct iavf_adapter *adapter,
eth_hw_addr_set(netdev, adapter->hw.mac.addr);
netif_addr_unlock_bh(netdev);
}
- wake_up(&adapter->vc_waitqueue);
break;
case VIRTCHNL_OP_GET_STATS: {
struct iavf_eth_stats *stats =
@@ -2956,3 +2966,73 @@ void iavf_virtchnl_completion(struct iavf_adapter *adapter,
} /* switch v_opcode */
adapter->current_op = VIRTCHNL_OP_UNKNOWN;
}
+
+/**
+ * iavf_poll_virtchnl_response - Poll admin queue for virtchnl response
+ * @adapter: adapter structure
+ * @condition: callback to check if desired response received
+ * @cond_data: context data passed to condition callback
+ * @timeout_ms: maximum time to wait in milliseconds
+ *
+ * Polls the admin queue and processes all incoming virtchnl messages.
+ * After processing each valid message, calls the condition callback to check
+ * if the expected response has been received. The callback receives the opcode
+ * of the processed message to identify which response was received. Continues
+ * polling until the callback returns true or timeout expires.
+ * Caller must hold netdev_lock. This can sleep for up to timeout_ms while
+ * polling hardware.
+ *
+ * Return: 0 on success (condition met), -EAGAIN on timeout, or error code
+ */
+int iavf_poll_virtchnl_response(struct iavf_adapter *adapter,
+ bool (*condition)(struct iavf_adapter *adapter,
+ const void *data,
+ enum virtchnl_ops v_op),
+ const void *cond_data,
+ unsigned int timeout_ms)
+{
+ struct iavf_hw *hw = &adapter->hw;
+ struct iavf_arq_event_info event;
+ enum virtchnl_ops received_op;
+ unsigned long timeout;
+ int ret = -EAGAIN;
+ u16 pending = 0;
+ u32 v_retval;
+
+ netdev_assert_locked(adapter->netdev);
+
+ event.buf_len = IAVF_MAX_AQ_BUF_SIZE;
+ event.msg_buf = kzalloc(event.buf_len, GFP_KERNEL);
+ if (!event.msg_buf)
+ return -ENOMEM;
+
+ timeout = jiffies + msecs_to_jiffies(timeout_ms);
+ do {
+ if (!pending)
+ usleep_range(50, 75);
+
+ if (iavf_clean_arq_element(hw, &event, &pending) == IAVF_SUCCESS) {
+ received_op = (enum virtchnl_ops)le32_to_cpu(event.desc.cookie_high);
+ if (received_op != VIRTCHNL_OP_UNKNOWN) {
+ v_retval = le32_to_cpu(event.desc.cookie_low);
+
+ iavf_virtchnl_completion(adapter, received_op,
+ (enum iavf_status)v_retval,
+ event.msg_buf, event.msg_len);
+
+ if (condition(adapter, cond_data, received_op)) {
+ ret = 0;
+ break;
+ }
+ }
+
+ memset(event.msg_buf, 0, IAVF_MAX_AQ_BUF_SIZE);
+
+ if (pending)
+ continue;
+ }
+ } while (time_before(jiffies, timeout));
+
+ kfree(event.msg_buf);
+ return ret;
+}
--
2.53.0
^ permalink raw reply related
* [PATCH net v5 4/4] ice: skip unnecessary VF reset when setting trust
From: Jose Ignacio Tornos Martinez @ 2026-04-29 10:24 UTC (permalink / raw)
To: netdev
Cc: intel-wired-lan, przemyslaw.kitszel, aleksandr.loktionov,
jacob.e.keller, horms, jesse.brandeburg, anthony.l.nguyen, davem,
edumazet, kuba, pabeni, Jose Ignacio Tornos Martinez
In-Reply-To: <20260429102426.210750-1-jtornosm@redhat.com>
Similar to the i40e fix, ice_set_vf_trust() unconditionally calls
ice_reset_vf() when the trust setting changes. While the delay is smaller
than i40e this reset is still unnecessary in most cases.
Additionally, the original code has a race condition: it deletes MAC LLDP
filters BEFORE resetting the VF. During this deletion, the VF is still
ACTIVE and can add new MAC LLDP filters concurrently, potentially
corrupting the filter list.
When granting trust, no reset is needed - we can just set the capability
flag to allow privileged operations.
When revoking trust, we only need to reset (conservative approach) if
the VF has actually configured advanced features that require cleanup
(MAC LLDP filters, promiscuous mode). For VFs in a clean state, we can
safely change the trust setting without the disruptive reset.
When we do reset (MAC LLDP case), we fix the race condition by resetting
first to clear VF state (which blocks new MAC LLDP filter additions), then
delete existing filters safely. During cleanup, vf->trusted remains true so
ice_vf_is_lldp_ena() works properly. Only after cleanup do we set
vf->trusted = false.
When we don't reset, we manually handle capability flag via helper
function, eliminating the delay.
Fixes: 2296345416b0 ("ice: receive LLDP on trusted VFs")
Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
---
v5 Address the comments from Aleksandr Loktionov:
- Error handling when ice_setup_vf_trust is called is not necessary
because ice_vf_clear_all_promisc_modes is not used due to the
conservative approach to solve AI tool review concerns
- kdoc should end with '*/' not '**/' (new function)
Address AI review (sashiko.dev) from Simon Horman:
- Adopt a conservative approach checking multiple conditions before
skipping reset: MAC LLDP filters, promiscuous mode
- Simplify helper function to only handle capability flag
- No need to export ice_vf_clear_all_promisc_modes
v4: https://lore.kernel.org/all/20260423130405.139568-5-jtornosm@redhat.com/
drivers/net/ethernet/intel/ice/ice_sriov.c | 33 +++++++++++++++++++---
1 file changed, 29 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_sriov.c b/drivers/net/ethernet/intel/ice/ice_sriov.c
index 7e00e091756d..3c64ed1b41a8 100644
--- a/drivers/net/ethernet/intel/ice/ice_sriov.c
+++ b/drivers/net/ethernet/intel/ice/ice_sriov.c
@@ -1364,6 +1364,23 @@ int ice_set_vf_mac(struct net_device *netdev, int vf_id, u8 *mac)
return __ice_set_vf_mac(ice_netdev_to_pf(netdev), vf_id, mac);
}
+/**
+ * ice_setup_vf_trust - Enable/disable VF trust mode without reset
+ * @vf: VF to configure
+ * @setting: trust setting
+ *
+ * Update VF flags when changing trust without performing a VF reset.
+ * This is only called when it's safe to skip the reset (VF has no advanced
+ * features configured that need cleanup).
+ */
+static void ice_setup_vf_trust(struct ice_vf *vf, bool setting)
+{
+ if (setting)
+ set_bit(ICE_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps);
+ else
+ clear_bit(ICE_VIRTCHNL_VF_CAP_PRIVILEGE, &vf->vf_caps);
+}
+
/**
* ice_set_vf_trust
* @netdev: network interface device structure
@@ -1399,11 +1416,19 @@ int ice_set_vf_trust(struct net_device *netdev, int vf_id, bool trusted)
mutex_lock(&vf->cfg_lock);
- while (!trusted && vf->num_mac_lldp)
- ice_vf_update_mac_lldp_num(vf, ice_get_vf_vsi(vf), false);
-
+ /* Reset only if revoking trust and VF has advanced features configured */
+ if (!trusted &&
+ (vf->num_mac_lldp > 0 ||
+ test_bit(ICE_VF_STATE_UC_PROMISC, vf->vf_states) ||
+ test_bit(ICE_VF_STATE_MC_PROMISC, vf->vf_states))) {
+ ice_reset_vf(vf, ICE_VF_RESET_NOTIFY);
+ while (vf->num_mac_lldp)
+ ice_vf_update_mac_lldp_num(vf, ice_get_vf_vsi(vf), false);
+ } else {
+ ice_setup_vf_trust(vf, trusted);
+ }
vf->trusted = trusted;
- ice_reset_vf(vf, ICE_VF_RESET_NOTIFY);
+
dev_info(ice_pf_to_dev(pf), "VF %u is now %strusted\n",
vf_id, trusted ? "" : "un");
--
2.53.0
^ permalink raw reply related
* Re: [RFC PATCH v1 7/9] x86: Add unsafe_copy_from_user()
From: Usama Arif @ 2026-04-29 10:25 UTC (permalink / raw)
To: Christophe Leroy (CS GROUP)
Cc: Usama Arif, Yury Norov, Andrew Morton, Linus Torvalds,
David Laight, Thomas Gleixner, linux-alpha, linux-kernel,
linux-snps-arc, linux-arm-kernel, linux-mips, linuxppc-dev, kvm,
linux-riscv, linux-s390, sparclinux, linux-um, dmaengine,
linux-efi, linux-fsi, amd-gfx, dri-devel, intel-gfx, linux-wpan,
netdev, linux-wireless, linux-spi, linux-media, linux-staging,
linux-serial, linux-usb, xen-devel, linux-fsdevel, ocfs2-devel,
bpf, kasan-dev, linux-mm, linux-x25, rust-for-linux, linux-sound,
sound-open-firmware, linux-csky, linux-hexagon, loongarch,
linux-m68k, linux-openrisc, linux-parisc, linux-sh, linux-arch
In-Reply-To: <0ee46bb228d97163fbdc14f2a7c52b93d8bc34ce.1777306795.git.chleroy@kernel.org>
On Mon, 27 Apr 2026 19:13:48 +0200 "Christophe Leroy (CS GROUP)" <chleroy@kernel.org> wrote:
> At the time being, x86 and arm64 are missing unsafe_copy_from_user().
>
> Add it.
>
> Signed-off-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
> ---
> arch/x86/include/asm/uaccess.h | 29 ++++++++++++++++++++++++-----
> 1 file changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/arch/x86/include/asm/uaccess.h b/arch/x86/include/asm/uaccess.h
> index 3a0dd3c2b233..10c458ffa399 100644
> --- a/arch/x86/include/asm/uaccess.h
> +++ b/arch/x86/include/asm/uaccess.h
> @@ -598,7 +598,7 @@ _label: \
> * We want the unsafe accessors to always be inlined and use
> * the error labels - thus the macro games.
> */
> -#define unsafe_copy_loop(dst, src, len, type, label) \
> +#define unsafe_put_loop(dst, src, len, type, label) \
> while (len >= sizeof(type)) { \
> unsafe_put_user(*(type *)(src),(type __user *)(dst),label); \
> dst += sizeof(type); \
> @@ -611,10 +611,29 @@ do { \
> char __user *__ucu_dst = (_dst); \
> const char *__ucu_src = (_src); \
> size_t __ucu_len = (_len); \
> - unsafe_copy_loop(__ucu_dst, __ucu_src, __ucu_len, u64, label); \
> - unsafe_copy_loop(__ucu_dst, __ucu_src, __ucu_len, u32, label); \
> - unsafe_copy_loop(__ucu_dst, __ucu_src, __ucu_len, u16, label); \
> - unsafe_copy_loop(__ucu_dst, __ucu_src, __ucu_len, u8, label); \
> + unsafe_put_loop(__ucu_dst, __ucu_src, __ucu_len, u64, label); \
> + unsafe_put_loop(__ucu_dst, __ucu_src, __ucu_len, u32, label); \
> + unsafe_put_loop(__ucu_dst, __ucu_src, __ucu_len, u16, label); \
> + unsafe_put_loop(__ucu_dst, __ucu_src, __ucu_len, u8, label); \
> +} while (0)
> +
> +#define unsafe_get_loop(dst, src, len, type, label) \
> + while (len >= sizeof(type)) { \
> + unsafe_get_user(*(type __user *)(src),(type *)(dst),label); \
Hi,
Just wanted to check if src and dst need to be swapped? Same for arm64 patch.
> + dst += sizeof(type); \
> + src += sizeof(type); \
> + len -= sizeof(type); \
> + }
> +
> +#define unsafe_copy_from_user(_dst,_src,_len,label) \
> +do { \
> + char *__ucu_dst = (_dst); \
> + const char __user *__ucu_src = (_src); \
> + size_t __ucu_len = (_len); \
> + unsafe_get_loop(__ucu_dst, __ucu_src, __ucu_len, u64, label); \
> + unsafe_get_loop(__ucu_dst, __ucu_src, __ucu_len, u32, label); \
> + unsafe_get_loop(__ucu_dst, __ucu_src, __ucu_len, u16, label); \
> + unsafe_get_loop(__ucu_dst, __ucu_src, __ucu_len, u8, label); \
> } while (0)
>
> #ifdef CONFIG_CC_HAS_ASM_GOTO_OUTPUT
> --
> 2.49.0
>
>
^ permalink raw reply
* Re: [PATCH net-next] net: Consistently define pci_device_ids using named initializers
From: Uwe Kleine-König (The Capable Hub) @ 2026-04-29 10:26 UTC (permalink / raw)
To: Andy Shevchenko
Cc: Michael Grzeschik, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Marc Kleine-Budde, Vincent Mailhol,
Krzysztof Halasa, Johannes Berg, Markus Schneider-Pargmann,
Steffen Klassert, David Dillow, Ion Badulescu, Mark Einon,
Rasesh Mody, GR-Linux-NIC-Dev, Manish Chopra, Potnuri Bharat Teja,
Denis Kirjanov, Jijie Shao, Jian Shen, Cai Huoqing, Fan Gong,
Tony Nguyen, Przemek Kitszel, Tariq Toukan, Saeed Mahameed,
Leon Romanovsky, Mark Bloch, Ido Schimmel, Petr Machata,
Yibo Dong, Simon Horman, Heiner Kallweit, nic_swsd, Jiri Pirko,
Francois Romieu, Daniele Venzano, Samuel Chessman, Jiawen Wu,
Mengyuan Lou, Kevin Curtis, Arend van Spriel, Stanislav Yakovlev,
Richard Cochran, Kees Cook, Thomas Gleixner, Thomas Fourier,
Ingo Molnar, Kory Maincent, Zilin Guan, Marco Crivellari,
Vadim Fedorenko, Jacob Keller, Philipp Stanner, Bjorn Helgaas,
Yeounsu Moon, Denis Benato, Yonglong Liu, Yicong Hui,
Randy Dunlap, MD Danish Anwar, Nathan Chancellor, Sai Krishna,
Ethan Nelson-Moore, Larysa Zaremba, Joe Damato, Double Lo,
Colin Ian King, netdev, linux-kernel, linux-can, linux-parisc,
intel-wired-lan, linux-rdma, oss-drivers, linux-wireless,
brcm80211, brcm80211-dev-list.pdl
In-Reply-To: <afGrPvUeZ-DjWbC8@ashevche-desk.local>
[-- Attachment #1: Type: text/plain, Size: 3039 bytes --]
[I dropped a few addresses from Cc: that bounced for me before.]
Hello Andy,
On Wed, Apr 29, 2026 at 09:54:54AM +0300, Andy Shevchenko wrote:
> On Tue, Apr 28, 2026 at 07:18:44PM +0200, Uwe Kleine-König (The Capable Hub) wrote:
> > ... and PCI device helpers.
> >
> > The various struct pci_device_id arrays were initialized mostly by one
> > the PCI_DEVICE macros and then list expressions. The latter isn't easily
> > readable if you're not into PCI. Using named initializers is more
> > explicit and thus easier to parse.
> >
> > Also use PCI_DEVICE* helper macros to assign .vendor, .device,
> > .subvendor and .subdevice where appropriate and skip explicit
> > assignments of 0 (which the compiler takes care of).
> >
> > The secret plan is to make struct pci_device_id::driver_data an
> > anonymous union (similar to
> > https://lore.kernel.org/all/cover.1776579304.git.u.kleine-koenig@baylibre.com/)
> > and that requires named initializers. But it's also a nice cleanup on
> > its own.
> >
> > This change doesn't introduce changes to the compiled pci_device_id
> > arrays. Tested on x86 and arm64.
>
> ...
>
> > - {0,} /* 0 terminated list. */
> > + { } /* 0 terminated list. */
>
> The comments like these are just noises.
Agreed, but I'd consider it out of scope for this patch to drop these
comments. That might also be subjective.
> The rule of thumb is to play with a
> trailing comma:
> - always drop it in the terminator entry
> - always keep it in the normal initialisers when semantically it's not a
> terminator
That was my intention. Will rework.
> > static const struct pci_device_id liquidio_pci_tbl[] = {
> > { /* 68xx */
> > - PCI_VENDOR_ID_CAVIUM, 0x91, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0
> > + PCI_VDEVICE(CAVIUM, 0x91)
>
> Use full fixed-width device id value(s). 0x0091 here and so on...
Sounds fair.
> > },
>
> Also seems that you may decrease number of LoC here putting it as
>
> { PCI_VDEVICE(CAVIUM, 0x0091) }, /* 68xx */
>
> and so on...
Agreed if all lines of an array can be compressed like that.
> > { /* 66xx */
> > - PCI_VENDOR_ID_CAVIUM, 0x92, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0
> > + PCI_VDEVICE(CAVIUM, 0x92)
> > },
> > { /* 23xx pf */
> > - PCI_VENDOR_ID_CAVIUM, 0x9702, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0
> > + PCI_VDEVICE(CAVIUM, 0x9702)
> > },
> > - {
> > - 0, 0, 0, 0, 0, 0, 0
> > - }
> > + { }
> > };
>
> ...
>
> > #define CH_PCI_DEVICE_ID_TABLE_DEFINE_END \
> > - { 0, } \
> > + { } \
> > }
>
> Why do we have this macro at all?
Over engineering? Reworking that also seems to be out of scope for this
patch to me.
> Also I somehow managed to remove, but I remember you had an inner comma in some
> cases after the .driver_data, when the full ID entry is located on a single
> line. I.o.w. do
>
> { PCI_...(), .driver_data = ... // no trailing comma here! },
That was also my intention. Will rework.
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH] net: Unify user-visible "Qualcomm" name
From: Simon Horman @ 2026-04-29 10:27 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Loic Poulain, Sergey Ryazanov, Johannes Berg, netdev,
linux-kernel, =Bjorn Andersson, Konrad Dybcio, linux-arm-msm
In-Reply-To: <ac91a635-4aeb-4fa2-a00a-0e3425caaea4@oss.qualcomm.com>
On Tue, Apr 28, 2026 at 06:28:24PM +0200, Krzysztof Kozlowski wrote:
> On 28/04/2026 18:14, Simon Horman wrote:
> > On Mon, Apr 27, 2026 at 09:01:27AM +0200, Krzysztof Kozlowski wrote:
> >> Various names for Qualcomm as a company are used in user-visible config
> >> options: QCOM, Qualcomm and Qualcomm Technologies. Switch to unified
> >> "Qualcomm" so it will be easier for users to identify the options when
> >> for example running menuconfig.
> >>
> >> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
> >
> > ...
> >
> >> diff --git a/drivers/net/wwan/Kconfig b/drivers/net/wwan/Kconfig
> >> index 88df55d78d90..958dbc7347fa 100644
> >> --- a/drivers/net/wwan/Kconfig
> >> +++ b/drivers/net/wwan/Kconfig
> >> @@ -38,7 +38,7 @@ config WWAN_HWSIM
> >> called wwan_hwsim. If unsure, say N.
> >>
> >> config MHI_WWAN_CTRL
> >> - tristate "MHI WWAN control driver for QCOM-based PCIe modems"
> >> + tristate "MHI WWAN control driver for Qualcomm-based PCIe modems"
> >> depends on MHI_BUS
> >> help
> >> MHI WWAN CTRL allows QCOM-based PCIe modems to expose different modem
> >
> > Hi Krzysztof,
> >
> > Sashiko points out that QCOM is still used on the line above.
> >
> >> @@ -51,7 +51,7 @@ config MHI_WWAN_CTRL
> >> called mhi_wwan_ctrl.
> >>
> >> config MHI_WWAN_MBIM
> >> - tristate "MHI WWAN MBIM network driver for QCOM-based PCIe modems"
> >> + tristate "MHI WWAN MBIM network driver for Qualcomm-based PCIe modems"
> >> depends on MHI_BUS
> >> help
> >> MHI WWAN MBIM is a WWAN network driver for QCOM-based PCIe modems.
> >
> > And here too.
>
> Yes, I did not unify every single text because I believe that might be
> more churn and not that much benefit. I think it is more important to
> have a list of drivers in xconfig or menuconfig nicely organized and the
> help message matters less.
>
> But if you wish, I can replace it there as well.
Thanks for clarifying.
I have no strong preference and am happy with this patch as-is.
Reviewed-by: Simon Horman <horms@kernel.org>
I see this was marked as changes requested.
Presumably due to my previous email.
Let's see if this helps.
pw-bot: under-review
^ permalink raw reply
* Re: [PATCH net-next] net: Consistently define pci_device_ids using named initializers
From: Uwe Kleine-König (The Capable Hub) @ 2026-04-29 10:30 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: Michael Grzeschik, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Vincent Mailhol, Krzysztof Halasa,
Johannes Berg, Markus Schneider-Pargmann, Steffen Klassert,
David Dillow, Ion Badulescu, Mark Einon, Rasesh Mody,
GR-Linux-NIC-Dev, Manish Chopra, Potnuri Bharat Teja,
Denis Kirjanov, Jijie Shao, Jian Shen, Cai Huoqing, Fan Gong,
Tony Nguyen, Przemek Kitszel, Tariq Toukan, Saeed Mahameed,
Leon Romanovsky, Mark Bloch, Ido Schimmel, Petr Machata,
Yibo Dong, Simon Horman, Heiner Kallweit, nic_swsd, Jiri Pirko,
Francois Romieu, Daniele Venzano, Samuel Chessman, Jiawen Wu,
Mengyuan Lou, Kevin Curtis, Arend van Spriel, Stanislav Yakovlev,
Richard Cochran, Kees Cook, Thomas Gleixner, Thomas Fourier,
Ingo Molnar, Kory Maincent, Zilin Guan, Marco Crivellari,
Vadim Fedorenko, Jacob Keller, Philipp Stanner, Bjorn Helgaas,
Yeounsu Moon, Denis Benato, Yonglong Liu, Andy Shevchenko,
Yicong Hui, Randy Dunlap, MD Danish Anwar, Nathan Chancellor,
Sai Krishna, Ethan Nelson-Moore, Larysa Zaremba, Joe Damato,
Double Lo, Colin Ian King, netdev, linux-kernel, linux-can,
linux-parisc, intel-wired-lan, linux-rdma, oss-drivers,
linux-wireless, brcm80211, brcm80211-dev-list.pdl
In-Reply-To: <20260429-responsible-clever-coyote-6b79f1-mkl@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]
Hello Marc,
On Wed, Apr 29, 2026 at 11:10:21AM +0200, Marc Kleine-Budde wrote:
> On 28.04.2026 19:18:44, Uwe Kleine-König (The Capable Hub) wrote:
> > },
> > - { 0,}
> > + { }
>
> Nitpick: can you convert the terminating entry to follow the same style
> as the rest of the driver:
>
> diff --git a/drivers/net/can/sja1000/plx_pci.c b/drivers/net/can/sja1000/plx_pci.c
> index a03553b80a5d..d69ff0ccfd94 100644
> --- a/drivers/net/can/sja1000/plx_pci.c
> +++ b/drivers/net/can/sja1000/plx_pci.c
> @@ -353,8 +353,8 @@ static const struct pci_device_id plx_pci_tbl[] = {
> PCI_DEVICE_SUB(ASEM_RAW_CAN_VENDOR_ID, ASEM_RAW_CAN_DEVICE_ID,
> ASEM_RAW_CAN_SUB_VENDOR_ID, ASEM_RAW_CAN_SUB_DEVICE_ID_BIS),
> .driver_data = (kernel_ulong_t)&plx_pci_card_info_asem_dual_can,
> - },
> - { }
> + }, {
> + }
> };
> MODULE_DEVICE_TABLE(pci, plx_pci_tbl);
That might be subjective. I also see some value to have the terminating
entry stand out a bit in the formatting and so I usually kept the entry
as it was.
If you prefer I can rework the can drivers at least to match your taste.
As you didn't object to have the can drivers converted as part of the
drivers/net patch, I assume that part is OK for you?!
Best regards
Uwe
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH net] ice: fix stats array overflow when VF requests more queues
From: Simon Horman @ 2026-04-29 10:32 UTC (permalink / raw)
To: Michal Schmidt
Cc: Tony Nguyen, Przemek Kitszel, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Jacob Keller,
Petr Oros, intel-wired-lan, netdev, linux-kernel
In-Reply-To: <20260427151827.43342-1-mschmidt@redhat.com>
On Mon, Apr 27, 2026 at 05:18:26PM +0200, Michal Schmidt wrote:
> When a VF increases its queue count via VIRTCHNL_OP_REQUEST_QUEUES,
> ice_vc_request_qs_msg() sets vf->num_req_qs and triggers a VF reset.
> The reset calls ice_vf_reconfig_vsi(), which does ice_vsi_decfg()
> followed by ice_vsi_cfg(). ice_vsi_decfg() does not free the per-ring
> stats arrays. Inside ice_vsi_cfg_def(), ice_vsi_set_num_qs() updates
> alloc_txq/alloc_rxq to the new larger value, but
> ice_vsi_alloc_stat_arrays() returns early because the stats already
> exist. ice_vsi_alloc_ring_stats() then iterates using the new larger
> alloc_txq and writes beyond the bounds of the old, smaller
> tx_ring_stats/rx_ring_stats pointer arrays, corrupting adjacent SLUB
> metadata.
...
> See the linked RHEL Jira item for a reproducer.
>
> Fixes: 2a2cb4c6c181 ("ice: replace ice_vf_recreate_vsi() with ice_vf_reconfig_vsi()")
> Closes: https://redhat.atlassian.net/browse/RHEL-164321
> Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
> Assisted-by: Claude:claude-opus-4-6 semcode
Reviewed-by: Simon Horman <horms@kernel.org>
FTR: There is an AI generated review of this patch available on sashiko.dev.
I believe the issues flagged there pre-date this patch and do not impact
this patch. So while I do not think they should block progress of this
patch I suggest looking over them to see if any follow-up is warranted.
^ 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