* [PATCH net] net: enetc: check the number of BDs needed for xdp_frame
From: wei.fang @ 2026-06-26 7:32 UTC (permalink / raw)
To: claudiu.manoil, vladimir.oltean, xiaoning.wang, andrew+netdev,
davem, edumazet, kuba, pabeni, ast, daniel, hawk, john.fastabend,
sdf
Cc: wei.fang, imx, netdev, linux-kernel, bpf
From: Wei Fang <wei.fang@nxp.com>
The size of xdp_redirect_arr array is ENETC_MAX_SKB_FRAGS. However, the
number of fragments contained in xdp_frame may be greater than or equal
to ENETC_MAX_SKB_FRAGS, which will cause the access to xdp_redirect_arr
to be out of bounds.
Fixes: 9d2b68cc108d ("net: enetc: add support for XDP_REDIRECT")
Signed-off-by: Wei Fang <wei.fang@nxp.com>
---
drivers/net/ethernet/freescale/enetc/enetc.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c b/drivers/net/ethernet/freescale/enetc/enetc.c
index aa8a87124b10..8e3f345dd9aa 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc.c
@@ -1783,6 +1783,7 @@ int enetc_xdp_xmit(struct net_device *ndev, int num_frames,
{
struct enetc_tx_swbd xdp_redirect_arr[ENETC_MAX_SKB_FRAGS] = {0};
struct enetc_ndev_priv *priv = netdev_priv(ndev);
+ struct skb_shared_info *shinfo;
struct enetc_bdr *tx_ring;
int xdp_tx_bd_cnt, i, k;
int xdp_tx_frm_cnt = 0;
@@ -1798,6 +1799,12 @@ int enetc_xdp_xmit(struct net_device *ndev, int num_frames,
prefetchw(ENETC_TXBD(*tx_ring, tx_ring->next_to_use));
for (k = 0; k < num_frames; k++) {
+ if (xdp_frame_has_frags(frames[k])) {
+ shinfo = xdp_get_shared_info_from_frame(frames[k]);
+ if (unlikely((shinfo->nr_frags + 1) > ENETC_MAX_SKB_FRAGS))
+ break;
+ }
+
xdp_tx_bd_cnt = enetc_xdp_frame_to_xdp_tx_swbd(tx_ring,
xdp_redirect_arr,
frames[k]);
--
2.34.1
^ permalink raw reply related
* [PATCH v2] vhost/net: fix clear_user start address in VHOST_GET_FEATURES_ARRAY
From: rom.wang @ 2026-06-26 7:04 UTC (permalink / raw)
To: Michael S . Tsirkin, Jason Wang, Eugenio Pérez, Paolo Abeni,
kvm, virtualization, netdev
Cc: linux-kernel, Yufeng Wang
From: Yufeng Wang <wangyufeng@kylinos.cn>
The clear_user() call in VHOST_GET_FEATURES_ARRAY incorrectly starts
at argp, which is the beginning of the features array, overwriting the
data just written by copy_to_user(). It should start after the copied
elements at argp + copied * sizeof(u64) to only zero the trailing
unused space.
Use size_mul() for both the offset and length calculations so the
arithmetic stays consistent with the surrounding code and remains
overflow-safe.
Fixes: 333c515d1896 ("vhost-net: allow configuring extended features")
Signed-off-by: Yufeng Wang <wangyufeng@kylinos.cn>
---
Changes in v2:
- Use size_mul() for the offset calculation as well, per review feedback.
Link to v1: https://lore.kernel.org/all/20260526080336.61296-1-r4o5m6e8o@163.com/
Note:
Thank you for your review and suggestions.
I tried to add a switch in tools/virtio/vhost_net_test.c.
The switch is meant to use VHOST_GET_FEATURES_ARRAY and
VHOST_SET_FEATURES_ARRAY instead of the legacy versions.
However, when I ran `make virtio` in the tools directory,
the build failed with an error: missing asm/percpu_types.h.
I fixed that error, but then another error appeared.
Would it be acceptable to postpone the submission of
this test case until I have sorted out all the build
errors?
---
drivers/vhost/net.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 77b59f49bddb..4b963dafa233 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -1784,7 +1784,8 @@ static long vhost_net_ioctl(struct file *f, unsigned int ioctl,
return -EFAULT;
/* Zero the trailing space provided by user-space, if any */
- if (clear_user(argp, size_mul(count - copied, sizeof(u64))))
+ if (clear_user(argp + size_mul(copied, sizeof(u64)),
+ size_mul(count - copied, sizeof(u64))))
return -EFAULT;
return 0;
case VHOST_SET_FEATURES_ARRAY:
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2] netfilter: nf_log: validate MAC header was set before dumping it
From: Greg KH @ 2026-06-26 6:51 UTC (permalink / raw)
To: Alexander Martyniuk
Cc: sashal, bestswngs, coreteam, davem, fw, kaber, kadlec, kuba,
kuznet, linux-kernel, netdev, netfilter-devel, pablo, stable,
xmei5, yoshfuji
In-Reply-To: <20260625164755.161383-1-alexevgmart@gmail.com>
On Thu, Jun 25, 2026 at 07:47:55PM +0300, Alexander Martyniuk wrote:
> From: Xiang Mei <xmei5@asu.edu>
>
> commit a84b6fedbc97078788be78dbdd7517d143ad1a77 upstream.
>
> The fallback path of dump_mac_header() guards the MAC header access
> only with "skb->mac_header != skb->network_header", without checking
> skb_mac_header_was_set(). When the MAC header is unset, mac_header is
> 0xffff, so the test passes and skb_mac_header(skb) returns
> skb->head + 0xffff, ~64 KiB past the buffer; the loop then reads
> dev->hard_header_len bytes out of bounds into the kernel log.
>
> This is reachable via the netdev logger: nf_log_unknown_packet() calls
> dump_mac_header() unconditionally, and an skb sent through AF_PACKET
> with PACKET_QDISC_BYPASS reaches the egress hook with mac_header still
> unset (__dev_queue_xmit(), which would reset it, is bypassed).
>
> Add the skb_mac_header_was_set() check the ARPHRD_ETHER path already
> uses, and replace the open-coded MAC header length test with
> skb_mac_header_len(). Only skbs with an unset MAC header are affected;
> valid ones are dumped as before.
>
> BUG: KASAN: slab-out-of-bounds in dump_mac_header (net/netfilter/nf_log_syslog.c:831)
> Read of size 1 at addr ffff88800ea49d3f by task exploit/148
> Call Trace:
> kasan_report (mm/kasan/report.c:595)
> dump_mac_header (net/netfilter/nf_log_syslog.c:831)
> nf_log_netdev_packet (net/netfilter/nf_log_syslog.c:938 net/netfilter/nf_log_syslog.c:963)
> nf_log_packet (net/netfilter/nf_log.c:260)
> nft_log_eval (net/netfilter/nft_log.c:60)
> nft_do_chain (net/netfilter/nf_tables_core.c:285)
> nft_do_chain_netdev (net/netfilter/nft_chain_filter.c:307)
> nf_hook_slow (net/netfilter/core.c:619)
> nf_hook_direct_egress (net/packet/af_packet.c:257)
> packet_xmit (net/packet/af_packet.c:280)
> packet_sendmsg (net/packet/af_packet.c:3114)
> __sys_sendto (net/socket.c:2265)
>
> Fixes: 7eb9282cd0ef ("netfilter: ipt_LOG/ip6t_LOG: add option to print decoded MAC header")
> Reported-by: Weiming Shi <bestswngs@gmail.com>
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Xiang Mei <xmei5@asu.edu>
> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
> Signed-off-by: Alexander Martyniuk <alexevgmart@gmail.com>
> ---
> net/ipv4/netfilter/nf_log_ipv4.c | 4 ++--
> net/ipv6/netfilter/nf_log_ipv6.c | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/net/ipv4/netfilter/nf_log_ipv4.c b/net/ipv4/netfilter/nf_log_ipv4.c
> index d07583fac8f8..d6164e8e2c73 100644
> --- a/net/ipv4/netfilter/nf_log_ipv4.c
> +++ b/net/ipv4/netfilter/nf_log_ipv4.c
> @@ -296,8 +296,8 @@ static void dump_ipv4_mac_header(struct nf_log_buf *m,
>
> fallback:
> nf_log_buf_add(m, "MAC=");
> - if (dev->hard_header_len &&
> - skb->mac_header != skb->network_header) {
> + if (dev->hard_header_len && skb_mac_header_was_set(skb) &&
> + skb_mac_header_len(skb) != 0) {
> const unsigned char *p = skb_mac_header(skb);
> unsigned int i;
>
> diff --git a/net/ipv6/netfilter/nf_log_ipv6.c b/net/ipv6/netfilter/nf_log_ipv6.c
> index 8210ff34ed9b..cc724870a467 100644
> --- a/net/ipv6/netfilter/nf_log_ipv6.c
> +++ b/net/ipv6/netfilter/nf_log_ipv6.c
> @@ -309,8 +309,8 @@ static void dump_ipv6_mac_header(struct nf_log_buf *m,
>
> fallback:
> nf_log_buf_add(m, "MAC=");
> - if (dev->hard_header_len &&
> - skb->mac_header != skb->network_header) {
> + if (dev->hard_header_len && skb_mac_header_was_set(skb) &&
> + skb_mac_header_len(skb) != 0) {
> const unsigned char *p = skb_mac_header(skb);
> unsigned int len = dev->hard_header_len;
> unsigned int i;
> --
> 2.43.0
>
>
What kernel(s) is this for?
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH v4 net 2/3] i40e: fix potential UAF in i40e_vsi_setup()'s error path
From: Loktionov, Aleksandr @ 2026-06-26 6:45 UTC (permalink / raw)
To: Fijalkowski, Maciej, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Karlsson, Magnus, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, Kitszel, Przemyslaw,
Keller, Jacob E, Fijalkowski, Maciej
In-Reply-To: <20260625151431.1102838-3-maciej.fijalkowski@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Maciej Fijalkowski
> Sent: Thursday, June 25, 2026 5:15 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Karlsson, Magnus
> <magnus.karlsson@intel.com>; kuba@kernel.org; pabeni@redhat.com;
> horms@kernel.org; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>;
> Keller, Jacob E <jacob.e.keller@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>
> Subject: [Intel-wired-lan] [PATCH v4 net 2/3] i40e: fix potential UAF
> in i40e_vsi_setup()'s error path
>
> Sashiko pointed out an issue where error path in
> i40e_vsi_reinit_setup() released ring memory but then when freeing
> q_vectors, the rings mapped to q_vectors where touched which implies a
> regular use-after-free bug.
>
> Apparently i40e_vsi_setup() has the same problem, so swap the
> allocation and freeing order and fix the 13 year old bug.
>
> Fixes: 41c445ff0f48 ("i40e: main driver core")
> Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_main.c | 12 ++++++------
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index 471fa7f7b643..4adc7b0fb2f4 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -14460,14 +14460,14 @@ struct i40e_vsi *i40e_vsi_setup(struct
> i40e_pf *pf, u8 type,
> fallthrough;
> case I40E_VSI_FDIR:
> /* set up vectors and rings if needed */
> - ret = i40e_vsi_setup_vectors(vsi);
> - if (ret)
> - goto err_msix;
> -
> ret = i40e_alloc_rings(vsi);
> if (ret)
> goto err_rings;
>
> + ret = i40e_vsi_setup_vectors(vsi);
> + if (ret)
> + goto err_qvec;
> +
> /* map all of the rings to the q_vectors */
> i40e_vsi_map_rings_to_vectors(vsi);
>
> @@ -14487,10 +14487,10 @@ struct i40e_vsi *i40e_vsi_setup(struct
> i40e_pf *pf, u8 type,
> return vsi;
>
> err_config:
> + i40e_vsi_free_q_vectors(vsi);
> +err_qvec:
> i40e_vsi_clear_rings(vsi);
> err_rings:
> - i40e_vsi_free_q_vectors(vsi);
> -err_msix:
> if (vsi->netdev_registered) {
> vsi->netdev_registered = false;
> unregister_netdev(vsi->netdev);
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH v4 net 1/3] i40e: unregister netdev before clearing VSI on reinit failure
From: Loktionov, Aleksandr @ 2026-06-26 6:45 UTC (permalink / raw)
To: Fijalkowski, Maciej, intel-wired-lan@lists.osuosl.org
Cc: netdev@vger.kernel.org, Karlsson, Magnus, kuba@kernel.org,
pabeni@redhat.com, horms@kernel.org, Kitszel, Przemyslaw,
Keller, Jacob E, Fijalkowski, Maciej
In-Reply-To: <20260625151431.1102838-2-maciej.fijalkowski@intel.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Maciej Fijalkowski
> Sent: Thursday, June 25, 2026 5:14 PM
> To: intel-wired-lan@lists.osuosl.org
> Cc: netdev@vger.kernel.org; Karlsson, Magnus
> <magnus.karlsson@intel.com>; kuba@kernel.org; pabeni@redhat.com;
> horms@kernel.org; Kitszel, Przemyslaw <przemyslaw.kitszel@intel.com>;
> Keller, Jacob E <jacob.e.keller@intel.com>; Fijalkowski, Maciej
> <maciej.fijalkowski@intel.com>
> Subject: [Intel-wired-lan] [PATCH v4 net 1/3] i40e: unregister netdev
> before clearing VSI on reinit failure
>
> i40e_vsi_reinit_setup() tears down the existing VSI queue/ring backing
> state before allocating replacement arrays and queue tracking. If one
> of these early allocations fails, the function jumps directly to
> err_vsi and calls i40e_vsi_clear().
>
> For a registered netdev, this frees the VSI while netdev_priv(netdev)-
> >vsi can still point at it, leaving the registered netdev with
> dangling private driver state.
>
> Split the error path so failures after destructive reinit teardown
> first unregister and free the netdev before clearing the VSI.
>
> Fixes: d2a69fefd756 ("i40e: Fix changing previously set
> num_queue_pairs for PFs")
> Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
> ---
> drivers/net/ethernet/intel/i40e/i40e_main.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/i40e/i40e_main.c
> b/drivers/net/ethernet/intel/i40e/i40e_main.c
> index a04683004a56..471fa7f7b643 100644
> --- a/drivers/net/ethernet/intel/i40e/i40e_main.c
> +++ b/drivers/net/ethernet/intel/i40e/i40e_main.c
> @@ -14274,7 +14274,7 @@ static struct i40e_vsi
> *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
> i40e_set_num_rings_in_vsi(vsi);
> ret = i40e_vsi_alloc_arrays(vsi, false);
> if (ret)
> - goto err_vsi;
> + goto err_netdev;
>
> alloc_queue_pairs = vsi->alloc_queue_pairs *
> (i40e_enabled_xdp_vsi(vsi) ? 2 : 1); @@ -
> 14284,7 +14284,7 @@ static struct i40e_vsi
> *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
> dev_info(&pf->pdev->dev,
> "failed to get tracking for %d queues for VSI %d
> err %d\n",
> alloc_queue_pairs, vsi->seid, ret);
> - goto err_vsi;
> + goto err_netdev;
> }
> vsi->base_queue = ret;
>
> @@ -14309,6 +14309,7 @@ static struct i40e_vsi
> *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
>
> err_rings:
> i40e_vsi_free_q_vectors(vsi);
> +err_netdev:
> if (vsi->netdev_registered) {
> vsi->netdev_registered = false;
> unregister_netdev(vsi->netdev);
> @@ -14318,7 +14319,6 @@ static struct i40e_vsi
> *i40e_vsi_reinit_setup(struct i40e_vsi *vsi)
> if (vsi->type == I40E_VSI_MAIN)
> i40e_devlink_destroy_port(pf);
> i40e_aq_delete_element(&pf->hw, vsi->seid, NULL);
> -err_vsi:
> i40e_vsi_clear(vsi);
> return NULL;
> }
> --
> 2.43.0
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH] ice: propagate ETH56G deskew read errors
From: Loktionov, Aleksandr @ 2026-06-26 6:45 UTC (permalink / raw)
To: Pengpeng Hou, Nguyen, Anthony L, Kitszel, Przemyslaw
Cc: Andrew Lunn, davem@davemloft.net, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Richard Cochran, intel-wired-lan@lists.osuosl.org,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20260625030305.85304-1-pengpeng@iscas.ac.cn>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Pengpeng Hou
> Sent: Thursday, June 25, 2026 5:03 AM
> To: Nguyen, Anthony L <anthony.l.nguyen@intel.com>; Kitszel,
> Przemyslaw <przemyslaw.kitszel@intel.com>
> Cc: Andrew Lunn <andrew+netdev@lunn.ch>; davem@davemloft.net; Eric
> Dumazet <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo
> Abeni <pabeni@redhat.com>; Richard Cochran <richardcochran@gmail.com>;
> intel-wired-lan@lists.osuosl.org; netdev@vger.kernel.org; linux-
> kernel@vger.kernel.org; pengpeng@iscas.ac.cn
> Subject: [Intel-wired-lan] [PATCH] ice: propagate ETH56G deskew read
> errors
>
> ice_ptp_calc_deskew_eth56g() returns a u32 deskew value, but it also
> returns the negative read_poll_timeout() error when the DESKEW valid
> bit never appears. That converts the negative error into a large
> unsigned deskew contribution, which can then be folded into the RX
> timestamp offset and programmed into hardware.
>
> Return the deskew value through an output parameter and propagate the
> read error from ice_phy_set_offsets_eth56g() instead of using it as
> offset data.
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
I recommend to add Fixes: tag, and proper net or net-next in [PATCH ] to steer properly your fix.
With the best regards
Alex
> ---
> drivers/net/ethernet/intel/ice/ice_ptp_hw.c | 27 +++++++++++++++-----
> -
> 1 file changed, 19 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> index 8e5f97835954..bd2e31b816a8 100644
> --- a/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> +++ b/drivers/net/ethernet/intel/ice/ice_ptp_hw.c
> @@ -1736,17 +1736,21 @@ static u32 ice_ptp_calc_bitslip_eth56g(struct
> ice_hw *hw, u8 port, u32 bs,
> * @ds: deskew multiplier
> * @rs: RS-FEC enabled
> * @spd: link speed
> + * @deskew: calculated deskew value
> *
> - * Return: calculated deskew value
> + * Return: 0 on success, negative error code otherwise
> */
> -static u32 ice_ptp_calc_deskew_eth56g(struct ice_hw *hw, u8 port, u32
> ds,
> - bool rs, enum ice_eth56g_link_spd
> spd)
> +static int ice_ptp_calc_deskew_eth56g(struct ice_hw *hw, u8 port, u32
> ds,
> + bool rs, enum ice_eth56g_link_spd
> spd,
> + u32 *deskew)
> {
> u32 deskew_i, deskew_f;
> int err;
>
> - if (!ds)
> + if (!ds) {
> + *deskew = 0;
> return 0;
> + }
>
> read_poll_timeout(ice_read_ptp_reg_eth56g, err,
> FIELD_GET(PHY_REG_DESKEW_0_VALID, deskew_i),
> 500, @@ -1766,7 +1770,9 @@ static u32
> ice_ptp_calc_deskew_eth56g(struct ice_hw *hw, u8 port, u32 ds,
> deskew_i = FIELD_PREP(ICE_ETH56G_MAC_CFG_RX_OFFSET_INT,
> deskew_i);
> /* Shift 3 fractional bits to the end of the integer part */
> deskew_f <<= ICE_ETH56G_MAC_CFG_FRAC_W -
> PHY_REG_DESKEW_0_RLEVEL_FRAC_W;
> - return mul_u32_u32_fx_q9(deskew_i | deskew_f, ds);
> + *deskew = mul_u32_u32_fx_q9(deskew_i | deskew_f, ds);
> +
> + return 0;
> }
>
> /**
> @@ -1789,6 +1795,7 @@ static int ice_phy_set_offsets_eth56g(struct
> ice_hw *hw, u8 port, {
> u32 rx_offset, tx_offset, bs_ds;
> bool onestep, sfd;
> + int err;
>
> onestep = hw->ptp.phy.eth56g.onestep_ena;
> sfd = hw->ptp.phy.eth56g.sfd_ena;
> @@ -1805,11 +1812,15 @@ static int ice_phy_set_offsets_eth56g(struct
> ice_hw *hw, u8 port,
> if (sfd)
> rx_offset = add_u32_u32_fx(rx_offset, cfg-
> >rx_offset.sfd);
>
> - if (spd < ICE_ETH56G_LNK_SPD_40G)
> + if (spd < ICE_ETH56G_LNK_SPD_40G) {
> bs_ds = ice_ptp_calc_bitslip_eth56g(hw, port, bs_ds, fc,
> rs,
> spd);
> - else
> - bs_ds = ice_ptp_calc_deskew_eth56g(hw, port, bs_ds, rs,
> spd);
> + } else {
> + err = ice_ptp_calc_deskew_eth56g(hw, port, bs_ds, rs,
> spd,
> + &bs_ds);
> + if (err)
> + return err;
> + }
> rx_offset = add_u32_u32_fx(rx_offset, bs_ds);
> rx_offset &= ICE_ETH56G_MAC_CFG_RX_OFFSET_INT |
> ICE_ETH56G_MAC_CFG_RX_OFFSET_FRAC;
> --
> 2.50.1 (Apple Git-155)
^ permalink raw reply
* [PATCH net v2] octeontx2-pf: check DMAC extraction support before filtering
From: nshettyj @ 2026-06-26 6:23 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: sgoutham, gakula, sbhatta, hkelam, bbhushan2, andrew+netdev,
davem, edumazet, kuba, pabeni, naveenm, tduszynski, sumang,
Nitin Shetty J
In-Reply-To: <20260625172552.258631-1-nshettyj@marvell.com>
From: Suman Ghosh <sumang@marvell.com>
Currently, configuring a VF MAC address via the PF (e.g., 'ip link
set <pf> vf 0 mac <mac>') blindly attempts to install a DMAC-based
hardware filter. However, the hardware parser profile might not
support DMAC extraction.
Check if the hardware parsing profile supports DMAC extraction
before adding the filter. Additionally, emit a warning message
to inform the operator if the MAC filter installation fails due
to missing DMAC extraction support.
Fixes: f0c2982aaf98 ("octeontx2-pf: Add support for SR-IOV management functions")
Signed-off-by: Suman Ghosh <sumang@marvell.com>
Signed-off-by: Nitin Shetty J <nshettyj@marvell.com>
---
v2:
- Move the DMAC extraction check from otx2_set_vf_mac() into
otx2_do_set_vf_mac() which already holds pf->mbox.lock, so all
mbox operations are under a single lock/unlock pair. All error
paths now use the existing goto-out pattern, eliminating the
scattered mutex_unlock() + return calls from v1.
- Return -EOPNOTSUPP instead of 0 when DMAC extraction is not
supported, so the caller gets an explicit error rather than a
silent success.
---
.../ethernet/marvell/octeontx2/nic/otx2_pf.c | 33 +++++++++++++++++++
1 file changed, 33 insertions(+)
diff --git a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
index b63df5737ff2..dc7e4a225dd0 100644
--- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
+++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
@@ -2517,10 +2517,43 @@ EXPORT_SYMBOL(otx2_config_hwtstamp_set);
static int otx2_do_set_vf_mac(struct otx2_nic *pf, int vf, const u8 *mac)
{
+ struct npc_get_field_status_req *freq;
+ struct npc_get_field_status_rsp *frsp;
struct npc_install_flow_req *req;
int err;
mutex_lock(&pf->mbox.lock);
+
+ /* Skip installing the DMAC filter if the hardware parser profile
+ * does not support DMAC extraction.
+ */
+ freq = otx2_mbox_alloc_msg_npc_get_field_status(&pf->mbox);
+ if (!freq) {
+ err = -ENOMEM;
+ goto out;
+ }
+
+ freq->field = NPC_DMAC;
+ if (otx2_sync_mbox_msg(&pf->mbox)) {
+ err = -EINVAL;
+ goto out;
+ }
+
+ frsp = (struct npc_get_field_status_rsp *)otx2_mbox_get_rsp
+ (&pf->mbox.mbox, 0, &freq->hdr);
+ if (IS_ERR(frsp)) {
+ err = PTR_ERR(frsp);
+ goto out;
+ }
+
+ if (!frsp->enable) {
+ netdev_warn(pf->netdev,
+ "VF %d MAC filter not installed: DMAC extraction not supported by parser profile\n",
+ vf);
+ err = -EOPNOTSUPP;
+ goto out;
+ }
+
req = otx2_mbox_alloc_msg_npc_install_flow(&pf->mbox);
if (!req) {
err = -ENOMEM;
--
2.48.1
^ permalink raw reply related
* Re: [syzbot] [net?] BUG: soft lockup in perf_event_open (2)
From: syzbot @ 2026-06-26 6:20 UTC (permalink / raw)
To: acme, adrian.hunter, alexander.shishkin, andrew, davem, edumazet,
eperezma, irogers, james.clark, jasowang, jolsa, kuba,
linux-kernel, linux-perf-users, mark.rutland, mingo, mst,
namhyung, netdev, pabeni, peterz, syzkaller-bugs, virtualization,
xuanzhuo
In-Reply-To: <69ad01b6.050a0220.310d8.0006.GAE@google.com>
syzbot has found a reproducer for the following issue on:
HEAD commit: 4edcdefd4083 Merge tag 'bpf-fixes' of git://git.kernel.org..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=16da941e580000
kernel config: https://syzkaller.appspot.com/x/.config?x=3c3d59be33cf7e9a
dashboard link: https://syzkaller.appspot.com/bug?extid=e04801269a8f6321dd79
compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=164054ea580000
Downloadable assets:
disk image (non-bootable): https://storage.googleapis.com/syzbot-assets/d900f083ada3/non_bootable_disk-4edcdefd.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/01cc5d298db0/vmlinux-4edcdefd.xz
kernel image: https://storage.googleapis.com/syzbot-assets/59e4cf862ca3/bzImage-4edcdefd.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+e04801269a8f6321dd79@syzkaller.appspotmail.com
rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
rcu: (detected by 0, t=10502 jiffies, g=61569, q=162 ncpus=1)
rcu: All QSes seen, last rcu_preempt kthread activity 10502 (4294967357-4294956855), jiffies_till_next_fqs=1, root ->qsmask 0x0
rcu: rcu_preempt kthread starved for 10502 jiffies! g61569 f0x2 RCU_GP_WAIT_FQS(5) ->state=0x0 ->cpu=0
rcu: Unless rcu_preempt kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_preempt state:R running task stack:27464 pid:16 tgid:16 ppid:2 task_flags:0x208040 flags:0x00080000
Call Trace:
<TASK>
context_switch kernel/sched/core.c:5510 [inline]
__schedule+0x17d9/0x56c0 kernel/sched/core.c:7234
__schedule_loop kernel/sched/core.c:7311 [inline]
schedule+0x164/0x2b0 kernel/sched/core.c:7326
schedule_timeout+0x152/0x2c0 kernel/time/sleep_timeout.c:99
rcu_gp_fqs_loop+0x30c/0x11f0 kernel/rcu/tree.c:2123
rcu_gp_kthread+0x9e/0x2b0 kernel/rcu/tree.c:2325
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
rcu: Stack dump where RCU GP kthread last ran:
CPU: 0 UID: 0 PID: 5714 Comm: syz.3.20 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
RIP: 0010:unwind_next_frame+0x19ae/0x2550 arch/x86/kernel/unwind_orc.c:677
Code: e8 03 42 0f b6 04 20 84 c0 0f 85 b6 0a 00 00 4c 89 e8 48 c1 e8 03 42 0f b6 04 20 84 c0 0f 85 c5 0a 00 00 48 0f bf 03 49 01 c0 <49> 8d 56 40 4c 89 f7 4c 89 c6 e8 33 0e 00 00 84 c0 0f 84 4e 01 00
RSP: 0018:ffffc900000074e0 EFLAGS: 00000283
RAX: fffffffffffffff0 RBX: ffffffff91709a28 RCX: 0000000000000000
RDX: ffffffff91709a2a RSI: 0000000000000008 RDI: ffffc900000075e8
RBP: 1ffffffff22e1345 R08: ffffc900034df7c8 R09: 0000000000000000
R10: ffffc900000075d8 R11: fffff52000000ebd R12: dffffc0000000000
R13: ffffffff91709a29 R14: ffffc90000007588 R15: ffffc900000075d0
FS: 0000555594cee500(0000) GS:ffff88808c81b000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f5209872780 CR3: 0000000035426000 CR4: 0000000000352ef0
Call Trace:
<IRQ>
arch_stack_walk+0x11b/0x150 arch/x86/kernel/stacktrace.c:25
stack_trace_save+0xa9/0x100 kernel/stacktrace.c:122
kasan_save_stack mm/kasan/common.c:57 [inline]
kasan_save_track+0x3e/0x80 mm/kasan/common.c:78
kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:584
poison_slab_object mm/kasan/common.c:253 [inline]
__kasan_slab_free+0x5c/0x80 mm/kasan/common.c:285
kasan_slab_free include/linux/kasan.h:235 [inline]
slab_free_hook mm/slub.c:2705 [inline]
slab_free mm/slub.c:6405 [inline]
kmem_cache_free+0x182/0x650 mm/slub.c:6532
kfree_skb_reason include/linux/skbuff.h:1323 [inline]
kfree_skb include/linux/skbuff.h:1332 [inline]
hsr_forward_skb+0x1a27/0x28c0 net/hsr/hsr_forward.c:753
send_hsr_supervision_frame+0x733/0xcf0 net/hsr/hsr_device.c:364
hsr_announce+0x1db/0x370 net/hsr/hsr_device.c:421
call_timer_fn+0x192/0x5e0 kernel/time/timer.c:1748
expire_timers kernel/time/timer.c:1799 [inline]
__run_timers kernel/time/timer.c:2374 [inline]
__run_timer_base+0x652/0x8b0 kernel/time/timer.c:2386
run_timer_base kernel/time/timer.c:2395 [inline]
run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2405
handle_softirqs+0x225/0x840 kernel/softirq.c:622
__do_softirq kernel/softirq.c:656 [inline]
invoke_softirq kernel/softirq.c:496 [inline]
__irq_exit_rcu+0xca/0x220 kernel/softirq.c:735
irq_exit_rcu+0x9/0x30 kernel/softirq.c:752
instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1062 [inline]
sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1062
</IRQ>
<TASK>
asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:674
RIP: 0010:finish_task_switch+0x417/0xc60 kernel/sched/core.c:5361
Code: 04 00 00 41 c7 84 24 20 0e 00 00 00 00 00 00 0f 1f 44 00 00 49 83 c4 48 4c 89 e7 e8 a3 5a 23 0a e8 6e bc 39 00 fb 4c 8b 65 c8 <49> 8d bc 24 f8 16 00 00 48 89 f8 48 c1 e8 03 42 0f b6 04 30 84 c0
RSP: 0018:ffffc900034df880 EFLAGS: 00000206
RAX: 00000000000009c3 RBX: ffff88801fc3bf20 RCX: 0000000080000001
RDX: 0000000000000006 RSI: ffffffff8dfe613c RDI: ffffffff8c2aaf80
RBP: ffffc900034df8d0 R08: ffffffff9032f8f7 R09: 1ffffffff2065f1e
R10: dffffc0000000000 R11: fffffbfff2065f1f R12: ffff88803292a540
R13: ffff88801fc3bee8 R14: dffffc0000000000 R15: 1ffff11003f877e4
context_switch kernel/sched/core.c:5513 [inline]
__schedule+0x17e1/0x56c0 kernel/sched/core.c:7234
preempt_schedule_common+0x82/0xd0 kernel/sched/core.c:7413
preempt_schedule_thunk+0x16/0x40 arch/x86/entry/thunk.S:12
__mutex_lock_common kernel/locking/mutex.c:656 [inline]
__mutex_lock+0x321/0x1550 kernel/locking/mutex.c:821
__do_sys_perf_event_open kernel/events/core.c:14249 [inline]
__se_sys_perf_event_open+0x1984/0x1d40 kernel/events/core.c:13881
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x174/0x580 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f520999ce59
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 e8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007ffd9f0e1458 EFLAGS: 00000246 ORIG_RAX: 000000000000012a
RAX: ffffffffffffffda RBX: 00007f5209c15fa0 RCX: 00007f520999ce59
RDX: bfffffffffffffff RSI: 0000000000000000 RDI: 0000200000000180
RBP: 00007f5209a32e6f R08: 0000000000000000 R09: 0000000000000000
R10: ffffffffffffffff R11: 0000000000000246 R12: 0000000000000000
R13: 00007f5209c15fac R14: 00007f5209c15fa0 R15: 00007f5209c15fa0
</TASK>
---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
^ permalink raw reply
* RE: [Intel-wired-lan] [TEST] Weird RSS state on ice
From: Loktionov, Aleksandr @ 2026-06-26 5:51 UTC (permalink / raw)
To: Jakub Kicinski, Pielech, Adrian
Cc: Kitszel, Przemyslaw, netdev@vger.kernel.org,
intel-wired-lan@lists.osuosl.org
In-Reply-To: <20260625190625.0f5ffe01@kernel.org>
> -----Original Message-----
> From: Jakub Kicinski <kuba@kernel.org>
> Sent: Friday, June 26, 2026 4:06 AM
> To: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>
> Cc: Pielech, Adrian <adrian.pielech@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; netdev@vger.kernel.org; intel-wired-
> lan@lists.osuosl.org
> Subject: Re: [Intel-wired-lan] [TEST] Weird RSS state on ice
>
> On Thu, 25 Jun 2026 07:11:14 +0000 Loktionov, Aleksandr wrote:
> > The patchset didn't help?
> >
> > [PATCH iwl-next v5 2/2] ice: implement symmetric RSS hash
> > configuration
>
> Not sure, it's not in tree, and lore doesn't want to point me at it
> either. What I don't get is how we get into the bad state in the first
> place.
>
> Looking at other tests today I spotted that rss flow label test is
> also behaving oddly. Most of the time the first case fails and the
> second
> passes:
>
> test "rss-flow-label-py"
> group "selftests-drivers-net-hw"
> result "fail"
> link "https://netdev-ci-results.intel.com/ice-results/net-next-hw-
> 2026-06-26--00-00/ice-E810-XXV4/rss_flow_label.py/stdout"
> results
> 0
> test "rss-flow-label-test-rss-flow-label"
> result "fail"
> 1
> test "rss-flow-label-test-rss-flow-label-6only"
> result "pass"
>
>
> But every now and then they skip:
>
> ok 1 rss_flow_label.test_rss_flow_label # SKIP Device doesn't support
> Flow Label for UDP6 ok 2 rss_flow_label.test_rss_flow_label_6only #
> SKIP Device doesn't support Flow Label for UDP6
>
> test "rss-flow-label-py"
> group "selftests-drivers-net-hw"
> result "skip"
> link "https://netdev-ci-results.intel.com/ice-results/net-next-hw-
> 2026-06-25--16-00/ice-E810-XXV4/rss_flow_label.py/stdout"
> results
> 0
> test "rss-flow-label-test-rss-flow-label"
> result "skip"
> 1
> test "rss-flow-label-test-rss-flow-label-6only"
> result "skip"
>
>
> The devlink info is identical so it must be that the device is in
> unclean state sometimes?? Do y'all power cycle these machines between
> runs?
Good day, Jakub
I heard from @Pielech, Adrian that we experienced infrastructure issues, but reboots helped us. Please ask him about CI infrastructure.
About my v5 March 16 symmetric RSS fix, which worked for me, I've just resent it today, please bless it.
With the best regards
Alex
^ permalink raw reply
* [PATCH iwl-next v5 2/2] ice: implement symmetric RSS hash configuration
From: Aleksandr Loktionov @ 2026-06-26 5:47 UTC (permalink / raw)
To: intel-wired-lan, anthony.l.nguyen, aleksandr.loktionov; +Cc: netdev
In-Reply-To: <20260626054730.1126969-1-aleksandr.loktionov@intel.com>
The driver advertises symmetric RSS support via supported_input_xfrm
but ice_set_rxfh() always programmed plain Toeplitz regardless of the
requested input_xfrm, making it impossible to actually enable symmetric
hashing.
Fix ice_set_rxfh() to honour rxfh->input_xfrm: program symmetric
Toeplitz (ICE_AQ_VSI_Q_OPT_RSS_HASH_SYM_TPLZ) when RXH_XFRM_SYM_XOR
is requested, revert to plain Toeplitz when the transform is cleared,
and skip the hardware write when the function has not changed.
Make ice_set_rss_vsi_ctx() non-static and export it so ice_set_rxfh()
can reprogram the VSI context directly. Change it to preserve
vsi->rss_hfunc across VSI reinitialisation instead of always resetting
to plain Toeplitz, which would silently undo any previously configured
symmetric hash function.
Fix ice_get_rxfh_fields() to report the hash fields actually programmed
in hardware. When the hardware hashes on only one half of an L3 or L4
pair, complete the pair in the reported bitmap to satisfy the kernel's
symmetry validator. For GTP flow types, report RXH_GTP_TEID honestly;
ethtool_rxfh_config_is_sym() now accepts TEID as an intrinsically
symmetric field (see preceding patch).
Tested with tools/testing/selftests/drivers/net/hw/rss_input_xfrm.py
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
---
drivers/net/ethernet/intel/ice/ice_ethtool.c | 40 ++++++++++++++++----
drivers/net/ethernet/intel/ice/ice_lib.c | 7 ++--
drivers/net/ethernet/intel/ice/ice_lib.h | 1 +
3 files changed, 37 insertions(+), 11 deletions(-)
diff --git a/drivers/net/ethernet/intel/ice/ice_ethtool.c b/drivers/net/ethernet/intel/ice/ice_ethtool.c
index c6bc29c..6ccfe36 100644
--- a/drivers/net/ethernet/intel/ice/ice_ethtool.c
+++ b/drivers/net/ethernet/intel/ice/ice_ethtool.c
@@ -3008,14 +3008,17 @@ ice_set_rxfh_fields(struct net_device *netdev,
return 0;
}
+#define ICE_RSS_L3_PAIR (RXH_IP_SRC | RXH_IP_DST)
+#define ICE_RSS_L4_PAIR (RXH_L4_B_0_1 | RXH_L4_B_2_3)
+
static int
ice_get_rxfh_fields(struct net_device *netdev, struct ethtool_rxfh_fields *nfc)
{
struct ice_netdev_priv *np = netdev_priv(netdev);
struct ice_vsi *vsi = np->vsi;
struct ice_pf *pf = vsi->back;
+ u64 l3, l4, hash_flds;
struct device *dev;
- u64 hash_flds;
bool symm;
u32 hdrs;
@@ -3067,6 +3070,13 @@ ice_get_rxfh_fields(struct net_device *netdev, struct ethtool_rxfh_fields *nfc)
hash_flds & ICE_FLOW_HASH_FLD_GTPU_DWN_TEID)
nfc->data |= (u64)RXH_GTP_TEID;
+ l3 = nfc->data & ICE_RSS_L3_PAIR;
+ l4 = nfc->data & ICE_RSS_L4_PAIR;
+ if (l3 && l3 != ICE_RSS_L3_PAIR)
+ nfc->data |= ICE_RSS_L3_PAIR;
+ if (l4 && l4 != ICE_RSS_L4_PAIR)
+ nfc->data |= ICE_RSS_L4_PAIR;
+
return 0;
}
@@ -3667,7 +3677,6 @@ ice_set_rxfh(struct net_device *netdev, struct ethtool_rxfh_param *rxfh,
struct netlink_ext_ack *extack)
{
struct ice_netdev_priv *np = netdev_priv(netdev);
- u8 hfunc = ICE_AQ_VSI_Q_OPT_RSS_HASH_TPLZ;
struct ice_vsi *vsi = np->vsi;
struct ice_pf *pf = vsi->back;
struct device *dev;
@@ -3689,13 +3698,28 @@ ice_set_rxfh(struct net_device *netdev, struct ethtool_rxfh_param *rxfh,
return -EOPNOTSUPP;
}
- /* Update the VSI's hash function */
- if (rxfh->input_xfrm & RXH_XFRM_SYM_XOR)
- hfunc = ICE_AQ_VSI_Q_OPT_RSS_HASH_SYM_TPLZ;
+ /* Handle RSS symmetric hash transformation */
+ if (rxfh->input_xfrm != RXH_XFRM_NO_CHANGE) {
+ u8 new_hfunc;
- err = ice_set_rss_hfunc(vsi, hfunc);
- if (err)
- return err;
+ if (rxfh->input_xfrm == RXH_XFRM_SYM_XOR)
+ new_hfunc = ICE_AQ_VSI_Q_OPT_RSS_HASH_SYM_TPLZ;
+ else if (!rxfh->input_xfrm)
+ new_hfunc = ICE_AQ_VSI_Q_OPT_RSS_HASH_TPLZ;
+ else
+ return -EOPNOTSUPP;
+
+ if (new_hfunc != vsi->rss_hfunc) {
+ err = ice_set_rss_hfunc(vsi, new_hfunc);
+ if (err) {
+ netdev_err(netdev, "Failed to set RSS hash function\n");
+ return err;
+ }
+ netdev_dbg(netdev, "RSS hash function: %sToeplitz\n",
+ new_hfunc == ICE_AQ_VSI_Q_OPT_RSS_HASH_SYM_TPLZ ?
+ "Symmetric " : "");
+ }
+ }
if (rxfh->key) {
if (!vsi->rss_hkey_user) {
diff --git a/drivers/net/ethernet/intel/ice/ice_lib.c b/drivers/net/ethernet/intel/ice/ice_lib.c
index d921269..5b1934b 100644
--- a/drivers/net/ethernet/intel/ice/ice_lib.c
+++ b/drivers/net/ethernet/intel/ice/ice_lib.c
@@ -1155,7 +1155,7 @@ static void ice_set_fd_vsi_ctx(struct ice_vsi_ctx *ctxt, struct ice_vsi *vsi)
* @ctxt: the VSI context being set
* @vsi: the VSI being configured
*/
-static void ice_set_rss_vsi_ctx(struct ice_vsi_ctx *ctxt, struct ice_vsi *vsi)
+void ice_set_rss_vsi_ctx(struct ice_vsi_ctx *ctxt, struct ice_vsi *vsi)
{
u8 lut_type, hash_type;
struct device *dev;
@@ -1181,8 +1181,9 @@ static void ice_set_rss_vsi_ctx(struct ice_vsi_ctx *ctxt, struct ice_vsi *vsi)
return;
}
- hash_type = ICE_AQ_VSI_Q_OPT_RSS_HASH_TPLZ;
- vsi->rss_hfunc = hash_type;
+ if (!vsi->rss_hfunc)
+ vsi->rss_hfunc = ICE_AQ_VSI_Q_OPT_RSS_HASH_TPLZ;
+ hash_type = vsi->rss_hfunc;
ctxt->info.q_opt_rss =
FIELD_PREP(ICE_AQ_VSI_Q_OPT_RSS_LUT_M, lut_type) |
diff --git a/drivers/net/ethernet/intel/ice/ice_lib.h b/drivers/net/ethernet/intel/ice/ice_lib.h
index 49454d98..29ba335 100644
--- a/drivers/net/ethernet/intel/ice/ice_lib.h
+++ b/drivers/net/ethernet/intel/ice/ice_lib.h
@@ -46,6 +46,7 @@ void ice_vsi_delete(struct ice_vsi *vsi);
int ice_vsi_cfg_tc(struct ice_vsi *vsi, u8 ena_tc);
int ice_vsi_cfg_rss_lut_key(struct ice_vsi *vsi);
+void ice_set_rss_vsi_ctx(struct ice_vsi_ctx *ctxt, struct ice_vsi *vsi);
void ice_vsi_cfg_netdev_tc(struct ice_vsi *vsi, u8 ena_tc);
--
2.52.0
^ permalink raw reply related
* [PATCH iwl-next v5 1/2] ethtool: treat RXH_GTP_TEID as intrinsically symmetric
From: Aleksandr Loktionov @ 2026-06-26 5:47 UTC (permalink / raw)
To: intel-wired-lan, anthony.l.nguyen, aleksandr.loktionov; +Cc: netdev
In-Reply-To: <20260626054730.1126969-1-aleksandr.loktionov@intel.com>
A GTP tunnel uses the same TEID value in both directions of a flow;
including TEID in the hash input does not break src/dst symmetry.
ethtool_rxfh_config_is_sym() currently rejects any hash field bitmap
that contains bits outside the four paired L3/L4 fields. This causes
drivers that hash GTP flows on TEID to fail the kernel's preflight
validation in ethtool_check_flow_types(), making it impossible for
those drivers to support symmetric-xor transforms at all.
Strip RXH_GTP_TEID from the bitmap before the paired-field check so
that drivers may honestly report TEID hashing without blocking the
configuration of symmetric transforms.
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
---
net/ethtool/common.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/net/ethtool/common.c b/net/ethtool/common.c
index 5fae329..9a3fd76 100644
--- a/net/ethtool/common.c
+++ b/net/ethtool/common.c
@@ -911,6 +911,9 @@ int ethtool_rxfh_config_is_sym(u64 rxfh)
{
bool sym;
+ /* Strip TEID before checking - it carries no src/dst asymmetry */
+ rxfh &= ~RXH_GTP_TEID;
+
sym = rxfh == (rxfh & (RXH_IP_SRC | RXH_IP_DST |
RXH_L4_B_0_1 | RXH_L4_B_2_3));
sym &= !!(rxfh & RXH_IP_SRC) == !!(rxfh & RXH_IP_DST);
--
2.52.0
^ permalink raw reply related
* [PATCH iwl-next v5 0/2] ice: implement symmetric RSS hash configuration
From: Aleksandr Loktionov @ 2026-06-26 5:47 UTC (permalink / raw)
To: intel-wired-lan, anthony.l.nguyen, aleksandr.loktionov; +Cc: netdev
The ice driver has advertised symmetric RSS support via
supported_input_xfrm since the capability was added, but ice_set_rxfh()
ignored the input_xfrm parameter entirely, so enabling symmetric hashing
had no actual effect.
This series fixes that. Patch 1 extends the ethtool core so that
drivers hashing GTP flows on TEID can report it honestly without
blocking symmetric-xor configuration. Patch 2 wires up the ice driver.
The need for patch 1 surfaced because GTP flow profiles in ice always
include TEID in the hash. ethtool_check_flow_types() calls
get_rxfh_fields() for every hashable flow type before allowing
symmetric-xor; ethtool_rxfh_config_is_sym() rejected any bitmap
containing RXH_GTP_TEID since it has no src/dst counterpart. TEID
is the same value in both tunnel directions, so this rejection is
incorrect: including it does not break symmetry.
Rather than hiding TEID from the reported fields (which would silently
misrepresent hardware behaviour), patch 1 fixes the validator, and
patch 2 reports TEID honestly.
Tested with tools/testing/selftests/drivers/net/hw/rss_input_xfrm.py
on an E810 card running kernel 6.19-rc8.
---
v4 -> v5:
- remove redundant (u64) type conversion
v3 -> v4:
- Drop the ICE_HASH_INVALID fallback in ice_get_rxfh_fields() that
fabricated default L3+L4 hash fields when no hardware RSS config
exists for a flow type; returning zero fields is more honest and
avoids misrepresenting hardware state
- Drop the companion "if (!l3 && !l4)" special case in the
pair-completion block; it was only necessary to cover the synthetic
defaults added by the fallback, which is now gone
- No functional change to ice_set_rxfh() or the ethtool core patch
v2 -> v3:
- Split into 2 patches: ethtool core fix separate from driver change
- Drop the RXH_GTP_TEID stripping workaround from the driver; instead
fix ethtool_rxfh_config_is_sym() to accept TEID as intrinsically
symmetric (patch 1)
- Fix ice_get_rxfh_fields(): the v2 unconditional assignment
"nfc->data = ICE_RSS_ALLOWED_FIELDS" clobbered fields set earlier in
the same function; replaced with pair-completion using |= so only
the missing half of a partial pair is filled in
- Remove ICE_RSS_ALLOWED_FIELDS define (no longer needed)
- Report RXH_GTP_TEID honestly for GTP flow types
v1 -> v2:
- Preserve valid symmetric RSS fields instead of overwriting nfc->data
unconditionally
Aleksandr Loktionov (2):
ethtool: treat RXH_GTP_TEID as intrinsically symmetric
ice: implement symmetric RSS hash configuration
drivers/net/ethernet/intel/ice/ice_ethtool.c | 40 +++++++++++++---
drivers/net/ethernet/intel/ice/ice_lib.c | 7 ++--
drivers/net/ethernet/intel/ice/ice_lib.h | 1 +
net/ethtool/common.c | 3 +++
4 files changed, 40 insertions(+), 11 deletions(-)
--
2.43.0
^ permalink raw reply
* [PATCH net] MAINTAINERS: Update Marvell octeontx2 driver maintainers
From: Ratheesh Kannoth @ 2026-06-26 4:48 UTC (permalink / raw)
To: netdev, linux-kernel
Cc: sgoutham, davem, edumazet, kuba, pabeni, andrew+netdev,
Ratheesh Kannoth
Update the maintainer entries for the Marvell OcteonTX (RVU) drivers to
reflect recent organizational changes.
Signed-off-by: Ratheesh Kannoth <rkannoth@marvell.com>
---
MAINTAINERS | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4a290dc1284e..6fda185033e3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15608,8 +15608,8 @@ F: drivers/net/ethernet/marvell/octeon_ep_vf
MARVELL OCTEONTX2 PHYSICAL FUNCTION DRIVER
M: Sunil Goutham <sgoutham@marvell.com>
M: Geetha sowjanya <gakula@marvell.com>
+M: Ratheesh Kannoth <rkannoth@marvell.com>
M: Subbaraya Sundeep <sbhatta@marvell.com>
-M: hariprasad <hkelam@marvell.com>
M: Bharat Bhushan <bbhushan2@marvell.com>
L: netdev@vger.kernel.org
S: Maintained
@@ -15618,9 +15618,8 @@ F: include/linux/soc/marvell/octeontx2/
MARVELL OCTEONTX2 RVU ADMIN FUNCTION DRIVER
M: Sunil Goutham <sgoutham@marvell.com>
-M: Linu Cherian <lcherian@marvell.com>
+M: Ratheesh Kannoth <rkannoth@marvell.com>
M: Geetha sowjanya <gakula@marvell.com>
-M: hariprasad <hkelam@marvell.com>
M: Subbaraya Sundeep <sbhatta@marvell.com>
L: netdev@vger.kernel.org
S: Maintained
@@ -15628,8 +15627,8 @@ F: Documentation/networking/device_drivers/ethernet/marvell/octeontx2.rst
F: drivers/net/ethernet/marvell/octeontx2/af/
MARVELL PEM PMU DRIVER
-M: Linu Cherian <lcherian@marvell.com>
M: Gowthami Thiagarajan <gthiagarajan@marvell.com>
+M: Geetha sowjanya <gakula@marvell.com>
S: Supported
F: drivers/perf/marvell_pem_pmu.c
--
2.43.0
^ permalink raw reply related
* [PATCH net v4] rtase: Workaround for TX hang caused by short UDP packets entering hardware PTP parsing
From: Justin Lai @ 2026-06-26 4:45 UTC (permalink / raw)
To: kuba
Cc: davem, edumazet, pabeni, andrew+netdev, linux-kernel, netdev,
stable, horms, richardcochran, david.laight.linux,
aleksander.lobakin, pkshih, larry.chiu, Justin Lai
The hardware performs additional PTP parsing on UDP packets identified
by destination ports 319/320 at the expected UDP destination port
offset.
If such a packet has transport data smaller than RTASE_MIN_PAD_LEN,
the parser may access data beyond the end of the packet and trigger a
TX hang.
For IPv4 fragmented packets, a non-initial fragment does not contain a
UDP header. However, if the payload contains values matching PTP
destination ports (319/320) at the expected UDP destination port
offset, the hardware incorrectly classifies the fragment as a PTP
packet and performs further parsing.
IPv6 fragmented packets are not affected because the hardware only
enters this parsing path when the IPv6 Next Header field directly
indicates UDP. Packets carrying a Fragment Header do not enter this
path.
Pad affected packets so the transport data reaches
RTASE_MIN_PAD_LEN before transmission to avoid triggering the
hardware issue.
Fixes: d6e882b89fdf ("rtase: Implement .ndo_start_xmit function")
Cc: stable@vger.kernel.org
Signed-off-by: Justin Lai <justinlai0215@realtek.com>
---
v3 -> v4:
- Derive the L3 protocol and network offset from Ethernet/VLAN
headers instead of relying on vlan_get_protocol().
- Reject malformed packets when the computed UDP offset exceeds
skb->len.
v2 -> v3:
- Remove dependency on skb_transport_header_was_set().
- Determine UDP header offset from IPv4/IPv6 headers.
- Use skb_header_pointer() for UDP header access.
- Add non-linear skb handling.
v1 -> v2:
- Remove RTASE_SHORT_PKT_THRESH and the packet length check.
- Check transport data length before parsing the UDP header.
- Add Fixes tag.
- Add Cc: stable@vger.kernel.org.
- Target net tree.
---
drivers/net/ethernet/realtek/rtase/rtase.h | 2 +
.../net/ethernet/realtek/rtase/rtase_main.c | 113 ++++++++++++++++++
2 files changed, 115 insertions(+)
diff --git a/drivers/net/ethernet/realtek/rtase/rtase.h b/drivers/net/ethernet/realtek/rtase/rtase.h
index b9209eb6ea73..d489d20177ac 100644
--- a/drivers/net/ethernet/realtek/rtase/rtase.h
+++ b/drivers/net/ethernet/realtek/rtase/rtase.h
@@ -359,4 +359,6 @@ struct rtase_private {
#define RTASE_MSS_MASK GENMASK(28, 18)
+#define RTASE_MIN_PAD_LEN 47
+
#endif /* RTASE_H */
diff --git a/drivers/net/ethernet/realtek/rtase/rtase_main.c b/drivers/net/ethernet/realtek/rtase/rtase_main.c
index 55105d34bc79..7dabf0004068 100644
--- a/drivers/net/ethernet/realtek/rtase/rtase_main.c
+++ b/drivers/net/ethernet/realtek/rtase/rtase_main.c
@@ -61,6 +61,7 @@
#include <linux/pci.h>
#include <linux/pm_runtime.h>
#include <linux/prefetch.h>
+#include <linux/ptp_classify.h>
#include <linux/rtnetlink.h>
#include <linux/tcp.h>
#include <asm/irq.h>
@@ -1249,6 +1250,115 @@ static u32 rtase_tx_csum(struct sk_buff *skb, const struct net_device *dev)
return csum_cmd;
}
+static bool rtase_get_l3_proto(struct sk_buff *skb, __be16 *proto,
+ u32 *network_offset)
+{
+ struct vlan_hdr *vh, _vh;
+ struct ethhdr *eh, _eh;
+ u32 offset = ETH_HLEN;
+
+ eh = skb_header_pointer(skb, 0, sizeof(_eh), &_eh);
+ if (!eh)
+ return false;
+
+ *proto = eh->h_proto;
+
+ while (eth_type_vlan(*proto)) {
+ vh = skb_header_pointer(skb, offset, sizeof(_vh), &_vh);
+ if (!vh)
+ return false;
+
+ *proto = vh->h_vlan_encapsulated_proto;
+ offset += VLAN_HLEN;
+ }
+
+ *network_offset = offset;
+
+ return true;
+}
+
+static bool rtase_get_udp_offset(struct sk_buff *skb, u32 *udp_offset)
+{
+ struct ipv6hdr *i6h, _i6h;
+ struct iphdr *ih, _ih;
+ __be16 proto;
+ u32 no;
+
+ if (!rtase_get_l3_proto(skb, &proto, &no))
+ return false;
+
+ switch (proto) {
+ case htons(ETH_P_IP):
+ ih = skb_header_pointer(skb, no, sizeof(_ih), &_ih);
+ if (!ih)
+ return false;
+
+ if (ih->ihl < 5)
+ return false;
+
+ if (ih->protocol != IPPROTO_UDP)
+ return false;
+
+ *udp_offset = no + ih->ihl * 4;
+
+ return true;
+ case htons(ETH_P_IPV6):
+ i6h = skb_header_pointer(skb, no, sizeof(_i6h), &_i6h);
+ if (!i6h)
+ return false;
+
+ if (i6h->nexthdr != IPPROTO_UDP)
+ return false;
+
+ *udp_offset = no + sizeof(*i6h);
+
+ return true;
+ default:
+ return false;
+ }
+}
+
+static bool rtase_skb_pad(struct sk_buff *skb)
+{
+ __be16 *dest, _dest;
+ u32 trans_data_len;
+ u32 udp_offset;
+ u16 dest_port;
+ u32 pad_len;
+
+ if (!rtase_get_udp_offset(skb, &udp_offset))
+ return true;
+
+ if (udp_offset > skb->len)
+ return false;
+
+ trans_data_len = skb->len - udp_offset;
+ if (trans_data_len < offsetof(struct udphdr, len) ||
+ trans_data_len >= RTASE_MIN_PAD_LEN)
+ return true;
+
+ dest = skb_header_pointer(skb,
+ udp_offset + offsetof(struct udphdr, dest),
+ sizeof(_dest), &_dest);
+ if (!dest)
+ return true;
+
+ dest_port = ntohs(*dest);
+ if (dest_port != PTP_EV_PORT && dest_port != PTP_GEN_PORT)
+ return true;
+
+ if (skb_is_nonlinear(skb)) {
+ if (skb_linearize(skb))
+ return false;
+ }
+
+ pad_len = RTASE_MIN_PAD_LEN - trans_data_len;
+ if (__skb_put_padto(skb, skb->len + pad_len, false))
+ return false;
+
+ return true;
+}
+
static int rtase_xmit_frags(struct rtase_ring *ring, struct sk_buff *skb,
u32 opts1, u32 opts2)
{
@@ -1362,6 +1472,9 @@ static netdev_tx_t rtase_start_xmit(struct sk_buff *skb,
opts2 |= rtase_tx_csum(skb, dev);
}
+ if (!rtase_skb_pad(skb))
+ goto err_dma_0;
+
frags = rtase_xmit_frags(ring, skb, opts1, opts2);
if (unlikely(frags < 0))
goto err_dma_0;
--
2.40.1
^ permalink raw reply related
* [PATCH net-next] caif: annotate phyinfo lookup under config lock
From: Runyu Xiao @ 2026-06-26 4:24 UTC (permalink / raw)
To: davem, edumazet, kuba, pabeni
Cc: horms, netdev, linux-kernel, runyu.xiao, jianhao.xu
cfcnfg_get_phyinfo_rcu() is used by both RCU read-side paths and config
update paths that hold cnfg->lock before adding or deleting entries from
cnfg->phys. The helper walks the list with list_for_each_entry_rcu(),
but does not tell lockdep about the config-lock-protected callers.
Pass lockdep_is_held(&cnfg->lock) to the iterator. RCU-reader callers
remain valid, and CONFIG_PROVE_RCU_LIST can now see the non-RCU
protection used by the add/delete paths.
This was found by our static analysis tool and then manually reviewed
against the current tree. The dynamic triage evidence is a
target-matched CONFIG_PROVE_RCU_LIST warning; the change is limited
to documenting the existing protection contract.
This is a lockdep annotation cleanup. It does not change CAIF phyinfo
list lifetime or update ordering.
Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
---
net/caif/cfcnfg.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/net/caif/cfcnfg.c b/net/caif/cfcnfg.c
index 52509e185960..6966cc9ab640 100644
--- a/net/caif/cfcnfg.c
+++ b/net/caif/cfcnfg.c
@@ -135,7 +135,8 @@ static struct cfcnfg_phyinfo *cfcnfg_get_phyinfo_rcu(struct cfcnfg *cnfg,
{
struct cfcnfg_phyinfo *phy;
- list_for_each_entry_rcu(phy, &cnfg->phys, node)
+ list_for_each_entry_rcu(phy, &cnfg->phys, node,
+ lockdep_is_held(&cnfg->lock))
if (phy->id == phyid)
return phy;
return NULL;
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] octeontx2-af: Fix pci_dev reference leak in cgx_print_dmac_flt
From: Ratheesh Kannoth @ 2026-06-26 4:20 UTC (permalink / raw)
To: Wentao Liang
Cc: Sunil Goutham, Linu Cherian, Geetha sowjanya, hariprasad,
Subbaraya Sundeep, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel, stable
In-Reply-To: <20260625063951.44361-1-vulab@iscas.ac.cn>
On 2026-06-25 at 12:09:51, Wentao Liang (vulab@iscas.ac.cn) wrote:
> In cgx_print_dmac_flt(), pci_get_device() is called to look up the AF
> PCI device, but its return value is passed directly to pci_get_drvdata()
> without saving the pointer. This means pci_dev_put() can never be called
> for the obtained device, causing a reference count leak.
>
> Fix it by saving the return value of pci_get_device() in a local variable
> and releasing it via pci_dev_put() after the drvdata is extracted.
>
> Cc: stable@vger.kernel.org
> Fixes: dbc52debf95f ("octeontx2-af: Debugfs support for DMAC filters")
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> .../net/ethernet/marvell/octeontx2/af/rvu_debugfs.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
> index fa461489acdd..90dc13df9ff9 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
> @@ -2949,7 +2949,7 @@ RVU_DEBUG_SEQ_FOPS(cgx_stat, cgx_stat_display, NULL);
>
> static int cgx_print_dmac_flt(struct seq_file *s, int lmac_id)
> {
> - struct pci_dev *pdev = NULL;
> + struct pci_dev *af_pdev, *pdev = NULL;
> void *cgxd = s->private;
> char *bcast, *mcast;
> u16 index, domain;
> @@ -2958,8 +2958,13 @@ static int cgx_print_dmac_flt(struct seq_file *s, int lmac_id)
> u64 cfg, mac;
> int pf;
>
> - rvu = pci_get_drvdata(pci_get_device(PCI_VENDOR_ID_CAVIUM,
> - PCI_DEVID_OCTEONTX2_RVU_AF, NULL));
> + af_pdev = pci_get_device(PCI_VENDOR_ID_CAVIUM,
> + PCI_DEVID_OCTEONTX2_RVU_AF, NULL);
> + if (!af_pdev)
> + return -ENODEV;
> +
> + rvu = pci_get_drvdata(af_pdev);
> + pci_dev_put(af_pdev);
> if (!rvu)
> return -ENODEV;
Thanks for bringing this up! It looks like this issue was resolved in a previous commit:
469f4462ec83 ("octeontx2-af: fix CGX debugfs RVU AF PCI reference leaks").
>
> --
> 2.39.5 (Apple Git-154)
>
^ permalink raw reply
* Re: [PATCH v29 0/5] Type2 device basic support
From: Richard Cheng @ 2026-06-26 3:56 UTC (permalink / raw)
To: alejandro.lucero-palau
Cc: linux-cxl, netdev, dan.j.williams, edward.cree, davem, kuba,
pabeni, edumazet, dave.jiang, Alejandro Lucero
In-Reply-To: <20260622124010.2192888-1-alejandro.lucero-palau@amd.com>
On Mon, Jun 22, 2026 at 01:40:05PM +0800, alejandro.lucero-palau@amd.com wrote:
> From: Alejandro Lucero <alucerop@amd.com>
>
> This series adds the last bits for allowing a CXL Type2 driver to obtain
> a CXL region linked to the device HDM decoders committed by the BIOS,
> with the driver being the sfc network driver.
>
> Changes from v28:
>
> - patch 1:
> fix doc (Ed Cree)
> fix error path (Sashiko)
>
> - patch 3:
> removing extra + char (sashiko)
>
> - path5:
> remove stray change (Ed Cree)
>
> Changes from v27:
>
> - patch 1: make driver probe failing if error in efx_cxl_init (Dan)
> - patch 4: add unmapping if error after efx_cxl_init (Dave)
> - patch 4/5: move cxl_pio_initialised from patch 4 to patch 5 (Dave)
>
> Tested in the cxl_for_7.3 branch.
>
Hi Alejandro,
The series looks fine to me with one small question in patch 4.
I don't have the required NIC to test it, and not enough knowledge to
give a deep enough review, I can just say it LGTM at this point.
I'll leave for other guru to give tags.
Thanks for this.
Best regards,
Richard Cheng.
> Alejandro Lucero (5):
> sfc: add cxl support
> cxl/sfc: Map cxl regs
> cxl/sfc: Initialize dpa without a mailbox
> sfc: obtain and map cxl range using devm_cxl_probe_mem
> sfc: support pio mapping based on cxl
>
> drivers/cxl/core/core.h | 2 +
> drivers/cxl/core/mbox.c | 51 +------------
> drivers/cxl/core/memdev.c | 67 ++++++++++++++++
> drivers/cxl/core/pci.c | 1 +
> drivers/cxl/core/port.c | 1 +
> drivers/cxl/core/regs.c | 1 +
> drivers/cxl/cxlpci.h | 12 ---
> drivers/cxl/pci.c | 1 +
> drivers/net/ethernet/sfc/Kconfig | 9 +++
> drivers/net/ethernet/sfc/Makefile | 1 +
> drivers/net/ethernet/sfc/ef10.c | 41 ++++++++--
> drivers/net/ethernet/sfc/efx.c | 18 ++++-
> drivers/net/ethernet/sfc/efx_cxl.c | 105 ++++++++++++++++++++++++++
> drivers/net/ethernet/sfc/efx_cxl.h | 32 ++++++++
> drivers/net/ethernet/sfc/net_driver.h | 10 +++
> drivers/net/ethernet/sfc/nic.h | 3 +
> include/cxl/cxl.h | 2 +
> include/cxl/pci.h | 22 ++++++
> 18 files changed, 309 insertions(+), 70 deletions(-)
> create mode 100644 drivers/net/ethernet/sfc/efx_cxl.c
> create mode 100644 drivers/net/ethernet/sfc/efx_cxl.h
> create mode 100644 include/cxl/pci.h
>
>
> base-commit: 9b1e70e8f9ec4b5c6ce7fa774a0023bb6894c686
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH v29 4/5] sfc: obtain and map cxl range using devm_cxl_probe_mem
From: Richard Cheng @ 2026-06-26 3:52 UTC (permalink / raw)
To: alejandro.lucero-palau
Cc: linux-cxl, netdev, dan.j.williams, edward.cree, davem, kuba,
pabeni, edumazet, dave.jiang, Alejandro Lucero, Edward Cree
In-Reply-To: <20260622124010.2192888-5-alejandro.lucero-palau@amd.com>
On Mon, Jun 22, 2026 at 01:40:09PM +0800, alejandro.lucero-palau@amd.com wrote:
> From: Alejandro Lucero <alucerop@amd.com>
>
> Use core API for safely obtain the CXL range linked to an HDM committed
> by the BIOS. Map such a range for being used as the ctpio buffer.
>
> A potential user space action through sysfs unbinding or core cxl
> modules remove will trigger sfc driver device detachment, with that case
> not racing with this mapping as this is done during driver probe and
> therefore protected with device lock against those user space actions.
>
> Signed-off-by: Alejandro Lucero <alucerop@amd.com>
> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> Acked-by: Edward Cree <ecree.xilinx@gmail.com>
> ---
> drivers/net/ethernet/sfc/efx.c | 2 ++
> drivers/net/ethernet/sfc/efx_cxl.c | 23 +++++++++++++++++++++++
> drivers/net/ethernet/sfc/efx_cxl.h | 3 +++
> 3 files changed, 28 insertions(+)
>
> diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
> index 61cbb6cfc360..3806cd3dd7f4 100644
> --- a/drivers/net/ethernet/sfc/efx.c
> +++ b/drivers/net/ethernet/sfc/efx.c
> @@ -984,6 +984,7 @@ static void efx_pci_remove(struct pci_dev *pci_dev)
> efx_fini_io(efx);
>
> probe_data = container_of(efx, struct efx_probe_data, efx);
> + efx_cxl_exit(probe_data);
>
> pci_dbg(efx->pci_dev, "shutdown successful\n");
>
> @@ -1242,6 +1243,7 @@ static int efx_pci_probe(struct pci_dev *pci_dev,
> return 0;
>
> fail3:
> + efx_cxl_exit(probe_data);
> efx_fini_io(efx);
> fail2:
> efx_fini_struct(efx);
> diff --git a/drivers/net/ethernet/sfc/efx_cxl.c b/drivers/net/ethernet/sfc/efx_cxl.c
> index 18b535b3ea40..3e7c950f83e9 100644
> --- a/drivers/net/ethernet/sfc/efx_cxl.c
> +++ b/drivers/net/ethernet/sfc/efx_cxl.c
> @@ -18,6 +18,7 @@ int efx_cxl_init(struct efx_probe_data *probe_data)
> {
> struct efx_nic *efx = &probe_data->efx;
> struct pci_dev *pci_dev = efx->pci_dev;
> + struct range cxl_pio_range;
> struct efx_cxl *cxl;
> u16 dvsec;
> int rc;
> @@ -73,9 +74,31 @@ int efx_cxl_init(struct efx_probe_data *probe_data)
> return -ENODEV;
> }
>
> + cxl->cxlmd = devm_cxl_probe_mem(&cxl->cxlds, &cxl_pio_range);
> + if (IS_ERR(cxl->cxlmd)) {
> + pci_err(pci_dev, "CXL accel memdev creation failed\n");
> + return PTR_ERR(cxl->cxlmd);
> + }
> +
> + cxl->ctpio_cxl = ioremap_wc(cxl_pio_range.start,
> + range_len(&cxl_pio_range));
Hi Alejandro,
A small question here,
Is it possible that the FW would commit a region bigger than the range ?
The committed CXL region length is never validated against the PIO window size.
The legacy patch sizes wc_mem_map_size to cover the VI-strided PIO offset, but
here we ioremap whatever the BIOS comitted and assume it's EFX_CTPIO_BUFFER_SIZE.
Maybe adding
"""
if (range_len(&cxl_pio_range) < EFX_CTPIO_BUFFER_SIZE)
return -EINVAL;
"""
Would be worthy ?
Let me know what you think.
Best regards,
Richard Cheng
> + if (!cxl->ctpio_cxl) {
> + pci_err(pci_dev, "CXL ioremap region (%pra) failed\n",
> + &cxl_pio_range);
> + return -ENOMEM;
> + }
> +
> probe_data->cxl = cxl;
>
> return 0;
> }
>
> +void efx_cxl_exit(struct efx_probe_data *probe_data)
> +{
> + if (!probe_data->cxl)
> + return;
> +
> + iounmap(probe_data->cxl->ctpio_cxl);
> +}
> +
> MODULE_IMPORT_NS("CXL");
> diff --git a/drivers/net/ethernet/sfc/efx_cxl.h b/drivers/net/ethernet/sfc/efx_cxl.h
> index 04e46278464d..3e2705cb063f 100644
> --- a/drivers/net/ethernet/sfc/efx_cxl.h
> +++ b/drivers/net/ethernet/sfc/efx_cxl.h
> @@ -20,10 +20,13 @@ struct efx_probe_data;
> struct efx_cxl {
> struct cxl_dev_state cxlds;
> struct cxl_memdev *cxlmd;
> + void __iomem *ctpio_cxl;
> };
>
> int efx_cxl_init(struct efx_probe_data *probe_data);
> +void efx_cxl_exit(struct efx_probe_data *probe_data);
> #else
> static inline int efx_cxl_init(struct efx_probe_data *probe_data) { return 0; }
> +static inline void efx_cxl_exit(struct efx_probe_data *probe_data) {}
> #endif
> #endif
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH v6 10/10] rust: module: update MAINTAINERS to cover module.rs
From: Alvin Sun @ 2026-06-26 3:01 UTC (permalink / raw)
To: Gary Guo, Miguel Ojeda, Boqun Feng, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Greg Kroah-Hartman,
Rafael J. Wysocki, David Airlie, Simona Vetter, Daniel Almeida,
Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar, Breno Leitao,
Jens Axboe, Dave Ertman, Leon Romanovsky, Igor Korotin,
FUJITA Tomonori, Bjorn Helgaas, Krzysztof Wilczyński,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas
Cc: rust-for-linux, linux-modules, driver-core, dri-devel, nova-gpu,
linux-kselftest, kunit-dev, linux-block, linux-kernel, netdev,
linux-pci
In-Reply-To: <DJI7HR91X68U.3BVK3U4OJC18B@garyguo.net>
On 6/25/26 22:39, Gary Guo wrote:
> On Wed Jun 24, 2026 at 4:00 PM BST, Alvin Sun wrote:
>> Module types now live in `rust/kernel/module.rs` alongside
>> `rust/kernel/module_param.rs`. Update the MODULE SUPPORT file pattern
>> from `rust/kernel/module_param.rs` to `rust/kernel/module*.rs` so both
>> files are covered.
>>
>> Assisted-by: opencode:glm-5.2
> Did you actually use a LLM for this patch even? :)
Yes, I've created a skill that generates commit messages for the code I
modify
manually.
>
>> Link: https://lore.kernel.org/rust-for-linux/8ea21b29-9baf-4926-a16f-7d21c5a1a1b8@suse.com
>> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
> This patch should probably be squashed into the actual move, i.e. patch 1.
Sure. Looking at the change history of the `MAINTAINERS` file, the
modifications
are always in standalone commits, so I followed the same convention.
Best regards,
Alvin
>
> Best,
> Gary
>
>> ---
>> MAINTAINERS | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index e035a3be797c4..74733de3e41ee 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -17984,7 +17984,7 @@ F: include/linux/module*.h
>> F: kernel/module/
>> F: lib/test_kmod.c
>> F: lib/tests/module/
>> -F: rust/kernel/module_param.rs
>> +F: rust/kernel/module*.rs
>> F: rust/macros/module.rs
>> F: scripts/module*
>> F: tools/testing/selftests/kmod/
>
^ permalink raw reply
* Re: [PATCH v6 07/10] rust: configfs: use `LocalModule` for `THIS_MODULE`
From: Alvin Sun @ 2026-06-26 2:35 UTC (permalink / raw)
To: Gary Guo, Miguel Ojeda, Boqun Feng, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Greg Kroah-Hartman,
Rafael J. Wysocki, David Airlie, Simona Vetter, Daniel Almeida,
Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar, Breno Leitao,
Jens Axboe, Dave Ertman, Leon Romanovsky, Igor Korotin,
FUJITA Tomonori, Bjorn Helgaas, Krzysztof Wilczyński,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas
Cc: rust-for-linux, linux-modules, driver-core, dri-devel, nova-gpu,
linux-kselftest, kunit-dev, linux-block, linux-kernel, netdev,
linux-pci
In-Reply-To: <DJI7IOXAD84M.2F6VSBY64BO62@garyguo.net>
On 6/25/26 22:40, Gary Guo wrote:
> On Wed Jun 24, 2026 at 4:00 PM BST, Alvin Sun wrote:
>> Replace the `THIS_MODULE` static reference in the `configfs_attrs!`
>> macro with `this_module::<LocalModule>()`, and update
>> rnull to import `LocalModule` instead of `THIS_MODULE`, consistent
>> with the move of `THIS_MODULE` into the `ModuleMetadata` trait.
>>
>> Assisted-by: opencode:glm-5.2
>> Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
>> Acked-by: Danilo Krummrich <dakr@kernel.org>
>> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
>> ---
>> drivers/block/rnull/configfs.rs | 6 ++----
>> rust/kernel/configfs.rs | 8 +++++---
>> 2 files changed, 7 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/block/rnull/configfs.rs b/drivers/block/rnull/configfs.rs
>> index c10a55fc58948..b2547ad1e5ddd 100644
>> --- a/drivers/block/rnull/configfs.rs
>> +++ b/drivers/block/rnull/configfs.rs
>> @@ -1,9 +1,7 @@
>> // SPDX-License-Identifier: GPL-2.0
>>
>> -use super::{
>> - NullBlkDevice,
>> - THIS_MODULE, //
>> -};
>> +use super::NullBlkDevice;
>> +use crate::LocalModule;
>> use kernel::{
>> block::mq::gen_disk::{
>> GenDisk,
>> diff --git a/rust/kernel/configfs.rs b/rust/kernel/configfs.rs
>> index 2339c6467325d..c31d7882e216d 100644
>> --- a/rust/kernel/configfs.rs
>> +++ b/rust/kernel/configfs.rs
>> @@ -875,7 +875,7 @@ fn as_ptr(&self) -> *const bindings::config_item_type {
>> /// configfs::Subsystem<Configuration>,
>> /// Configuration
>> /// >::new_with_child_ctor::<N,Child>(
>> -/// &THIS_MODULE,
>> +/// ::kernel::module::this_module::<crate::LocalModule>(),
>> /// &CONFIGURATION_ATTRS
>> /// );
>> ///
>> @@ -1021,7 +1021,8 @@ macro_rules! configfs_attrs {
>>
>> static [< $data:upper _TPE >] : $crate::configfs::ItemType<$container, $data> =
>> $crate::configfs::ItemType::<$container, $data>::new::<N>(
>> - &THIS_MODULE, &[<$ data:upper _ATTRS >]
>> + $crate::module::this_module::<LocalModule>(),
> ^ You only changed one single place. This is still plain `LocalModule`.
Initially I wrote it as `crate::LocalModule`, but clippy warned about it. So
instead of putting the crate path in the macro body, I added `use
crate::LocalModule` in the calling file.
```
warning: `crate` references the macro call's crate
--> rust/kernel/configfs.rs:1024:59
|
1024 | ... $crate::module::this_module::<crate::LocalModule>(),
| ^^^^^ help:
to reference the macro definition's crate, use: `$crate`
|
= help: for further information visit
https://rust-lang.github.io/rust-clippy/rust-1.94.0/index.html#crate_in_macro_def
= note: `-W clippy::crate-in-macro-def` implied by `-W clippy::all`
= help: to override `-W clippy::all` add
`#[allow(clippy::crate_in_macro_def)]`
warning: 1 warning emitted
```
Alternatively, `#[allow(clippy::crate_in_macro_def)]` could be added on
the macro
definition. Would you suggest that approach?
Best regards,
Alvin
>
> Best,
> Gary
>
>> + &[<$ data:upper _ATTRS >]
>> );
>> )?
>>
>> @@ -1030,7 +1031,8 @@ macro_rules! configfs_attrs {
>> $crate::configfs::ItemType<$container, $data> =
>> $crate::configfs::ItemType::<$container, $data>::
>> new_with_child_ctor::<N, $child>(
>> - &THIS_MODULE, &[<$ data:upper _ATTRS >]
>> + $crate::module::this_module::<LocalModule>(),
>> + &[<$ data:upper _ATTRS >]
>> );
>> )?
>>
>
^ permalink raw reply
* [PATCH v2] lib/random32: convert selftest to KUnit
From: Kir Chou @ 2026-06-26 2:34 UTC (permalink / raw)
To: akpm
Cc: thomas.weissschuh, davidgow, geert, visitorckw, brendan.higgins,
linux-kselftest, kunit-dev, Kir Chou, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
open list, open list:NETWORKING [GENERAL]
This patch converts the existing prandom selftest (lib/random32.c) to use
the KUnit framework (lib/tests/random32_kunit.c). Unlike typical KUnit
tests, this file is directly #included into lib/random32.c.
The new test:
- Removes the legacy CONFIG_RANDOM32_SELFTEST from lib/random32.c.
- Adds CONFIG_PRANDOM_KUNIT_TEST (defaulting to KUNIT_ALL_TESTS).
- Moves the test logic to lib/tests/random32_kunit.c.
v2:
- Removes the legacy CONFIG_RANDOM32_SELFTEST from lib/Kconfig.
- Add const to arrays in lib/tests/random32_kunit.c.
This commit is verified by `./tools/testing/kunit/kunit.py run`
with the .kunit/.kunitconfig:
```
CONFIG_KUNIT=y
CONFIG_PRANDOM_KUNIT_TEST=y
```
Signed-off-by: Kir Chou <note351@hotmail.com>
---
lib/Kconfig | 6 --
lib/Kconfig.debug | 9 ++
lib/random32.c | 173 +-----------------------------------
lib/tests/random32_kunit.c | 174 +++++++++++++++++++++++++++++++++++++
4 files changed, 185 insertions(+), 177 deletions(-)
create mode 100644 lib/tests/random32_kunit.c
diff --git a/lib/Kconfig b/lib/Kconfig
index 2923924be..5f185e9f1 100644
--- a/lib/Kconfig
+++ b/lib/Kconfig
@@ -156,12 +156,6 @@ config AUDIT_COMPAT_GENERIC
depends on AUDIT_GENERIC && AUDIT_ARCH_COMPAT_GENERIC && COMPAT
default y
-config RANDOM32_SELFTEST
- bool "PRNG perform self test on init"
- help
- This option enables the 32 bit PRNG library functions to perform a
- self test on initialization.
-
#
# compression support is select'ed if needed
#
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index ba36939fd..0214a5859 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -3354,6 +3354,15 @@ config PRIME_NUMBERS_KUNIT_TEST
If unsure, say N
+config PRANDOM_KUNIT_TEST
+ tristate "KUnit test for prandom" if !KUNIT_ALL_TESTS
+ depends on KUNIT
+ default KUNIT_ALL_TESTS
+ help
+ Enable this option to test the prandom functions at runtime.
+
+ If unsure, say N
+
endif # RUNTIME_TESTING_MENU
config ARCH_USE_MEMTEST
diff --git a/lib/random32.c b/lib/random32.c
index 24e7acd93..0aab36792 100644
--- a/lib/random32.c
+++ b/lib/random32.c
@@ -126,175 +126,6 @@ void prandom_seed_full_state(struct rnd_state __percpu *pcpu_state)
}
EXPORT_SYMBOL(prandom_seed_full_state);
-#ifdef CONFIG_RANDOM32_SELFTEST
-static struct prandom_test1 {
- u32 seed;
- u32 result;
-} test1[] = {
- { 1U, 3484351685U },
- { 2U, 2623130059U },
- { 3U, 3125133893U },
- { 4U, 984847254U },
-};
-
-static struct prandom_test2 {
- u32 seed;
- u32 iteration;
- u32 result;
-} test2[] = {
- /* Test cases against taus113 from GSL library. */
- { 931557656U, 959U, 2975593782U },
- { 1339693295U, 876U, 3887776532U },
- { 1545556285U, 961U, 1615538833U },
- { 601730776U, 723U, 1776162651U },
- { 1027516047U, 687U, 511983079U },
- { 416526298U, 700U, 916156552U },
- { 1395522032U, 652U, 2222063676U },
- { 366221443U, 617U, 2992857763U },
- { 1539836965U, 714U, 3783265725U },
- { 556206671U, 994U, 799626459U },
- { 684907218U, 799U, 367789491U },
- { 2121230701U, 931U, 2115467001U },
- { 1668516451U, 644U, 3620590685U },
- { 768046066U, 883U, 2034077390U },
- { 1989159136U, 833U, 1195767305U },
- { 536585145U, 996U, 3577259204U },
- { 1008129373U, 642U, 1478080776U },
- { 1740775604U, 939U, 1264980372U },
- { 1967883163U, 508U, 10734624U },
- { 1923019697U, 730U, 3821419629U },
- { 442079932U, 560U, 3440032343U },
- { 1961302714U, 845U, 841962572U },
- { 2030205964U, 962U, 1325144227U },
- { 1160407529U, 507U, 240940858U },
- { 635482502U, 779U, 4200489746U },
- { 1252788931U, 699U, 867195434U },
- { 1961817131U, 719U, 668237657U },
- { 1071468216U, 983U, 917876630U },
- { 1281848367U, 932U, 1003100039U },
- { 582537119U, 780U, 1127273778U },
- { 1973672777U, 853U, 1071368872U },
- { 1896756996U, 762U, 1127851055U },
- { 847917054U, 500U, 1717499075U },
- { 1240520510U, 951U, 2849576657U },
- { 1685071682U, 567U, 1961810396U },
- { 1516232129U, 557U, 3173877U },
- { 1208118903U, 612U, 1613145022U },
- { 1817269927U, 693U, 4279122573U },
- { 1510091701U, 717U, 638191229U },
- { 365916850U, 807U, 600424314U },
- { 399324359U, 702U, 1803598116U },
- { 1318480274U, 779U, 2074237022U },
- { 697758115U, 840U, 1483639402U },
- { 1696507773U, 840U, 577415447U },
- { 2081979121U, 981U, 3041486449U },
- { 955646687U, 742U, 3846494357U },
- { 1250683506U, 749U, 836419859U },
- { 595003102U, 534U, 366794109U },
- { 47485338U, 558U, 3521120834U },
- { 619433479U, 610U, 3991783875U },
- { 704096520U, 518U, 4139493852U },
- { 1712224984U, 606U, 2393312003U },
- { 1318233152U, 922U, 3880361134U },
- { 855572992U, 761U, 1472974787U },
- { 64721421U, 703U, 683860550U },
- { 678931758U, 840U, 380616043U },
- { 692711973U, 778U, 1382361947U },
- { 677703619U, 530U, 2826914161U },
- { 92393223U, 586U, 1522128471U },
- { 1222592920U, 743U, 3466726667U },
- { 358288986U, 695U, 1091956998U },
- { 1935056945U, 958U, 514864477U },
- { 735675993U, 990U, 1294239989U },
- { 1560089402U, 897U, 2238551287U },
- { 70616361U, 829U, 22483098U },
- { 368234700U, 731U, 2913875084U },
- { 20221190U, 879U, 1564152970U },
- { 539444654U, 682U, 1835141259U },
- { 1314987297U, 840U, 1801114136U },
- { 2019295544U, 645U, 3286438930U },
- { 469023838U, 716U, 1637918202U },
- { 1843754496U, 653U, 2562092152U },
- { 400672036U, 809U, 4264212785U },
- { 404722249U, 965U, 2704116999U },
- { 600702209U, 758U, 584979986U },
- { 519953954U, 667U, 2574436237U },
- { 1658071126U, 694U, 2214569490U },
- { 420480037U, 749U, 3430010866U },
- { 690103647U, 969U, 3700758083U },
- { 1029424799U, 937U, 3787746841U },
- { 2012608669U, 506U, 3362628973U },
- { 1535432887U, 998U, 42610943U },
- { 1330635533U, 857U, 3040806504U },
- { 1223800550U, 539U, 3954229517U },
- { 1322411537U, 680U, 3223250324U },
- { 1877847898U, 945U, 2915147143U },
- { 1646356099U, 874U, 965988280U },
- { 805687536U, 744U, 4032277920U },
- { 1948093210U, 633U, 1346597684U },
- { 392609744U, 783U, 1636083295U },
- { 690241304U, 770U, 1201031298U },
- { 1360302965U, 696U, 1665394461U },
- { 1220090946U, 780U, 1316922812U },
- { 447092251U, 500U, 3438743375U },
- { 1613868791U, 592U, 828546883U },
- { 523430951U, 548U, 2552392304U },
- { 726692899U, 810U, 1656872867U },
- { 1364340021U, 836U, 3710513486U },
- { 1986257729U, 931U, 935013962U },
- { 407983964U, 921U, 728767059U },
-};
-
-static void prandom_state_selftest_seed(struct rnd_state *state, u32 seed)
-{
-#define LCG(x) ((x) * 69069U) /* super-duper LCG */
- state->s1 = __seed(LCG(seed), 2U);
- state->s2 = __seed(LCG(state->s1), 8U);
- state->s3 = __seed(LCG(state->s2), 16U);
- state->s4 = __seed(LCG(state->s3), 128U);
-}
-
-static int __init prandom_state_selftest(void)
-{
- int i, j, errors = 0, runs = 0;
- bool error = false;
-
- for (i = 0; i < ARRAY_SIZE(test1); i++) {
- struct rnd_state state;
-
- prandom_state_selftest_seed(&state, test1[i].seed);
- prandom_warmup(&state);
-
- if (test1[i].result != prandom_u32_state(&state))
- error = true;
- }
-
- if (error)
- pr_warn("prandom: seed boundary self test failed\n");
- else
- pr_info("prandom: seed boundary self test passed\n");
-
- for (i = 0; i < ARRAY_SIZE(test2); i++) {
- struct rnd_state state;
-
- prandom_state_selftest_seed(&state, test2[i].seed);
- prandom_warmup(&state);
-
- for (j = 0; j < test2[i].iteration - 1; j++)
- prandom_u32_state(&state);
-
- if (test2[i].result != prandom_u32_state(&state))
- errors++;
-
- runs++;
- cond_resched();
- }
-
- if (errors)
- pr_warn("prandom: %d/%d self tests failed\n", errors, runs);
- else
- pr_info("prandom: %d self tests passed\n", runs);
- return 0;
-}
-core_initcall(prandom_state_selftest);
+#ifdef CONFIG_PRANDOM_KUNIT_TEST
+#include "tests/random32_kunit.c"
#endif
diff --git a/lib/tests/random32_kunit.c b/lib/tests/random32_kunit.c
new file mode 100644
index 000000000..13c657b00
--- /dev/null
+++ b/lib/tests/random32_kunit.c
@@ -0,0 +1,174 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Test cases for random32 functions.
+ */
+
+#include <kunit/test.h>
+
+static const struct prandom_test1 {
+ u32 seed;
+ u32 result;
+} test1[] = {
+ { 1U, 3484351685U },
+ { 2U, 2623130059U },
+ { 3U, 3125133893U },
+ { 4U, 984847254U },
+};
+
+static const struct prandom_test2 {
+ u32 seed;
+ u32 iteration;
+ u32 result;
+} test2[] = {
+ /* Test cases against taus113 from GSL library. */
+ { 931557656U, 959U, 2975593782U },
+ { 1339693295U, 876U, 3887776532U },
+ { 1545556285U, 961U, 1615538833U },
+ { 601730776U, 723U, 1776162651U },
+ { 1027516047U, 687U, 511983079U },
+ { 416526298U, 700U, 916156552U },
+ { 1395522032U, 652U, 2222063676U },
+ { 366221443U, 617U, 2992857763U },
+ { 1539836965U, 714U, 3783265725U },
+ { 556206671U, 994U, 799626459U },
+ { 684907218U, 799U, 367789491U },
+ { 2121230701U, 931U, 2115467001U },
+ { 1668516451U, 644U, 3620590685U },
+ { 768046066U, 883U, 2034077390U },
+ { 1989159136U, 833U, 1195767305U },
+ { 536585145U, 996U, 3577259204U },
+ { 1008129373U, 642U, 1478080776U },
+ { 1740775604U, 939U, 1264980372U },
+ { 1967883163U, 508U, 10734624U },
+ { 1923019697U, 730U, 3821419629U },
+ { 442079932U, 560U, 3440032343U },
+ { 1961302714U, 845U, 841962572U },
+ { 2030205964U, 962U, 1325144227U },
+ { 1160407529U, 507U, 240940858U },
+ { 635482502U, 779U, 4200489746U },
+ { 1252788931U, 699U, 867195434U },
+ { 1961817131U, 719U, 668237657U },
+ { 1071468216U, 983U, 917876630U },
+ { 1281848367U, 932U, 1003100039U },
+ { 582537119U, 780U, 1127273778U },
+ { 1973672777U, 853U, 1071368872U },
+ { 1896756996U, 762U, 1127851055U },
+ { 847917054U, 500U, 1717499075U },
+ { 1240520510U, 951U, 2849576657U },
+ { 1685071682U, 567U, 1961810396U },
+ { 1516232129U, 557U, 3173877U },
+ { 1208118903U, 612U, 1613145022U },
+ { 1817269927U, 693U, 4279122573U },
+ { 1510091701U, 717U, 638191229U },
+ { 365916850U, 807U, 600424314U },
+ { 399324359U, 702U, 1803598116U },
+ { 1318480274U, 779U, 2074237022U },
+ { 697758115U, 840U, 1483639402U },
+ { 1696507773U, 840U, 577415447U },
+ { 2081979121U, 981U, 3041486449U },
+ { 955646687U, 742U, 3846494357U },
+ { 1250683506U, 749U, 836419859U },
+ { 595003102U, 534U, 366794109U },
+ { 47485338U, 558U, 3521120834U },
+ { 619433479U, 610U, 3991783875U },
+ { 704096520U, 518U, 4139493852U },
+ { 1712224984U, 606U, 2393312003U },
+ { 1318233152U, 922U, 3880361134U },
+ { 855572992U, 761U, 1472974787U },
+ { 64721421U, 703U, 683860550U },
+ { 678931758U, 840U, 380616043U },
+ { 692711973U, 778U, 1382361947U },
+ { 677703619U, 530U, 2826914161U },
+ { 92393223U, 586U, 1522128471U },
+ { 1222592920U, 743U, 3466726667U },
+ { 358288986U, 695U, 1091956998U },
+ { 1935056945U, 958U, 514864477U },
+ { 735675993U, 990U, 1294239989U },
+ { 1560089402U, 897U, 2238551287U },
+ { 70616361U, 829U, 22483098U },
+ { 368234700U, 731U, 2913875084U },
+ { 20221190U, 879U, 1564152970U },
+ { 539444654U, 682U, 1835141259U },
+ { 1314987297U, 840U, 1801114136U },
+ { 2019295544U, 645U, 3286438930U },
+ { 469023838U, 716U, 1637918202U },
+ { 1843754496U, 653U, 2562092152U },
+ { 400672036U, 809U, 4264212785U },
+ { 404722249U, 965U, 2704116999U },
+ { 600702209U, 758U, 584979986U },
+ { 519953954U, 667U, 2574436237U },
+ { 1658071126U, 694U, 2214569490U },
+ { 420480037U, 749U, 3430010866U },
+ { 690103647U, 969U, 3700758083U },
+ { 1029424799U, 937U, 3787746841U },
+ { 2012608669U, 506U, 3362628973U },
+ { 1535432887U, 998U, 42610943U },
+ { 1330635533U, 857U, 3040806504U },
+ { 1223800550U, 539U, 3954229517U },
+ { 1322411537U, 680U, 3223250324U },
+ { 1877847898U, 945U, 2915147143U },
+ { 1646356099U, 874U, 965988280U },
+ { 805687536U, 744U, 4032277920U },
+ { 1948093210U, 633U, 1346597684U },
+ { 392609744U, 783U, 1636083295U },
+ { 690241304U, 770U, 1201031298U },
+ { 1360302965U, 696U, 1665394461U },
+ { 1220090946U, 780U, 1316922812U },
+ { 447092251U, 500U, 3438743375U },
+ { 1613868791U, 592U, 828546883U },
+ { 523430951U, 548U, 2552392304U },
+ { 726692899U, 810U, 1656872867U },
+ { 1364340021U, 836U, 3710513486U },
+ { 1986257729U, 931U, 935013962U },
+ { 407983964U, 921U, 728767059U },
+};
+
+static void prandom_state_test_seed(struct rnd_state *state, u32 seed)
+{
+#define LCG(x) ((x) * 69069U) /* super-duper LCG */
+ state->s1 = __seed(LCG(seed), 2U);
+ state->s2 = __seed(LCG(state->s1), 8U);
+ state->s3 = __seed(LCG(state->s2), 16U);
+ state->s4 = __seed(LCG(state->s3), 128U);
+}
+
+static void test_prandom_seed_boundary(struct kunit *test)
+{
+ int i;
+ struct rnd_state state;
+
+ for (i = 0; i < ARRAY_SIZE(test1); i++) {
+ prandom_state_test_seed(&state, test1[i].seed);
+ prandom_warmup(&state);
+ KUNIT_EXPECT_EQ(test, test1[i].result, prandom_u32_state(&state));
+ }
+}
+
+static void test_prandom_taus113(struct kunit *test)
+{
+ int i, j;
+ struct rnd_state state;
+
+ for (i = 0; i < ARRAY_SIZE(test2); i++) {
+ prandom_state_test_seed(&state, test2[i].seed);
+ prandom_warmup(&state);
+
+ for (j = 0; j < test2[i].iteration - 1; j++)
+ prandom_u32_state(&state);
+
+ KUNIT_EXPECT_EQ(test, test2[i].result, prandom_u32_state(&state));
+ }
+}
+
+static struct kunit_case prandom_test_cases[] = {
+ KUNIT_CASE(test_prandom_seed_boundary),
+ KUNIT_CASE(test_prandom_taus113),
+ {}
+};
+
+static struct kunit_suite prandom_test_suite = {
+ .name = "prandom",
+ .test_cases = prandom_test_cases,
+};
+
+kunit_test_suite(prandom_test_suite);
--
2.52.0
^ permalink raw reply related
* Re: [PATCH net] net: ethtool: keep rtnl_lock for ops using ethtool_op_get_link()
From: patchwork-bot+netdevbpf @ 2026-06-26 2:31 UTC (permalink / raw)
To: Jakub Kicinski
Cc: davem, netdev, edumazet, pabeni, andrew+netdev, horms, leitao,
joshwash, hramamurthy, anthony.l.nguyen, przemyslaw.kitszel,
saeedm, tariqt, mbloch, leon, alexanderduyck, kernel-team, kys,
haiyangz, wei.liu, decui, longli, jordanrhee, jacob.e.keller,
nktgrg, debarghyak, mohsin.bashr, ernis, sdf, gal, linux-rdma,
linux-hyperv
In-Reply-To: <20260624190439.2521219-1-kuba@kernel.org>
Hello:
This patch was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 24 Jun 2026 12:04:39 -0700 you wrote:
> Breno reports following splats on mlx5:
>
> RTNL: assertion failed at net/core/dev.c (2241)
> WARNING: net/core/dev.c:2241 at netif_state_change+0xed/0x130, CPU#5: ethtool/1335
> RIP: 0010:netif_state_change+0xf9/0x130
> Call Trace:
> <TASK>
> __linkwatch_sync_dev+0xea/0x120
> ethtool_op_get_link+0xe/0x20
> __ethtool_get_link+0x26/0x40
> linkstate_prepare_data+0x51/0x200
> ethnl_default_doit+0x213/0x470
> genl_family_rcv_msg_doit+0xdd/0x110
>
> [...]
Here is the summary with links:
- [net] net: ethtool: keep rtnl_lock for ops using ethtool_op_get_link()
https://git.kernel.org/netdev/net/c/1105ef941c1a
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH net v3 00/11] rxrpc: Miscellaneous fixes
From: patchwork-bot+netdevbpf @ 2026-06-26 2:31 UTC (permalink / raw)
To: David Howells
Cc: netdev, marc.dionne, kuba, davem, edumazet, pabeni, horms,
linux-afs, linux-kernel
In-Reply-To: <20260624163819.3017002-1-dhowells@redhat.com>
Hello:
This series was applied to netdev/net.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Wed, 24 Jun 2026 17:38:07 +0100 you wrote:
> Here are some miscellaneous AF_RXRPC fixes for more stuff found by Sashiko[1][2]:
>
> (1) Fix ACKALL handling by adding two more call states to simplify when
> ACKs are valid.
>
> (2) Fix connection leak from AF_RXRPC recvmsg userspace OOB handling.
>
> [...]
Here is the summary with links:
- [net,v3,01/11] rxrpc: Fix ACKALL packet handling
https://git.kernel.org/netdev/net/c/9b6ce5948085
- [net,v3,02/11] rxrpc: Fix leak of connection from OOB challenge
https://git.kernel.org/netdev/net/c/4b28876e78fd
- [net,v3,03/11] rxrpc: Fix double unlock in rxrpc_recvmsg()
https://git.kernel.org/netdev/net/c/a2f299b4d551
- [net,v3,04/11] afs: Fix further netns teardown to cancel the preallocation charger
https://git.kernel.org/netdev/net/c/2daf8ac812c3
- [net,v3,05/11] afs: Fix uncancelled rxrpc OOB message handler
https://git.kernel.org/netdev/net/c/a4057e58b070
- [net,v3,06/11] rxrpc: Fix the reception of a reply packet before data transmission
https://git.kernel.org/netdev/net/c/a58e33405acd
- [net,v3,07/11] rxrpc: Fix oob challenge leak in cleanup after notification failure
https://git.kernel.org/netdev/net/c/092275882aec
- [net,v3,08/11] rxrpc: Fix potential infinite loop in rxrpc_recvmsg()
https://git.kernel.org/netdev/net/c/67a0332f442e
- [net,v3,09/11] rxrpc: Fix socket notification race
https://git.kernel.org/netdev/net/c/e66f8f32f501
- [net,v3,10/11] rxrpc: Fix leak of released call in recvmsg(MSG_PEEK)
https://git.kernel.org/netdev/net/c/4bdb9e471f5b
- [net,v3,11/11] rxrpc: Fix rxrpc_rotate_tx_rotate() to check there's something to rotate
https://git.kernel.org/netdev/net/c/a5462da5a349
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH] MAINTAINERS: Update Jason Wang's email address
From: Jason Wang @ 2026-06-26 2:20 UTC (permalink / raw)
To: mst, virtualization, netdev; +Cc: eperezma, kvm, linux-kernel, Jason Wang
I will use jasowangio@gmail.com for future review and discussion.
Signed-off-by: Jason Wang <jasowang@redhat.com>
---
MAINTAINERS | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 15011f5752a9..40d9641cbc7a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -27520,7 +27520,7 @@ F: drivers/net/ethernet/dec/tulip/
TUN/TAP DRIVER
M: Willem de Bruijn <willemdebruijn.kernel@gmail.com>
-M: Jason Wang <jasowang@redhat.com>
+M: Jason Wang <jasowangio@gmail.com>
S: Maintained
W: http://vtun.sourceforge.net/tun
F: Documentation/networking/tuntap.rst
@@ -28512,7 +28512,7 @@ F: include/uapi/linux/virtio_balloon.h
VIRTIO BLOCK AND SCSI DRIVERS
M: "Michael S. Tsirkin" <mst@redhat.com>
-M: Jason Wang <jasowang@redhat.com>
+M: Jason Wang <jasowangio@gmail.com>
R: Paolo Bonzini <pbonzini@redhat.com>
R: Stefan Hajnoczi <stefanha@redhat.com>
R: Eugenio Pérez <eperezma@redhat.com>
@@ -28541,7 +28541,7 @@ F: include/uapi/linux/virtio_console.h
VIRTIO CORE
M: "Michael S. Tsirkin" <mst@redhat.com>
-M: Jason Wang <jasowang@redhat.com>
+M: Jason Wang <jasowangio@gmail.com>
R: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
R: Eugenio Pérez <eperezma@redhat.com>
L: virtualization@lists.linux.dev
@@ -28619,7 +28619,7 @@ F: include/uapi/linux/virtio_gpu.h
VIRTIO HOST (VHOST)
M: "Michael S. Tsirkin" <mst@redhat.com>
-M: Jason Wang <jasowang@redhat.com>
+M: Jason Wang <jasowangio@gmail.com>
R: Eugenio Pérez <eperezma@redhat.com>
L: kvm@vger.kernel.org
L: virtualization@lists.linux.dev
@@ -28634,7 +28634,7 @@ F: kernel/vhost_task.c
VIRTIO HOST (VHOST-SCSI)
M: "Michael S. Tsirkin" <mst@redhat.com>
-M: Jason Wang <jasowang@redhat.com>
+M: Jason Wang <jasowangio@gmail.com>
M: Mike Christie <michael.christie@oracle.com>
R: Paolo Bonzini <pbonzini@redhat.com>
R: Stefan Hajnoczi <stefanha@redhat.com>
@@ -28674,7 +28674,7 @@ F: include/uapi/linux/virtio_mem.h
VIRTIO NET DRIVER
M: "Michael S. Tsirkin" <mst@redhat.com>
-M: Jason Wang <jasowang@redhat.com>
+M: Jason Wang <jasowangio@gmail.com>
R: Xuan Zhuo <xuanzhuo@linux.alibaba.com>
R: Eugenio Pérez <eperezma@redhat.com>
L: netdev@vger.kernel.org
--
2.54.0
^ permalink raw reply related
* Re: [Intel-wired-lan] [TEST] Weird RSS state on ice
From: Jakub Kicinski @ 2026-06-26 2:06 UTC (permalink / raw)
To: Loktionov, Aleksandr
Cc: Pielech, Adrian, Kitszel, Przemyslaw, netdev@vger.kernel.org,
intel-wired-lan@lists.osuosl.org
In-Reply-To: <DS4PPF7551E65529A34C04A73F4287C2B4EE5EC2@DS4PPF7551E6552.namprd11.prod.outlook.com>
On Thu, 25 Jun 2026 07:11:14 +0000 Loktionov, Aleksandr wrote:
> The patchset didn't help?
>
> [PATCH iwl-next v5 2/2] ice: implement symmetric RSS hash configuration
Not sure, it's not in tree, and lore doesn't want to point me at it
either. What I don't get is how we get into the bad state in the first
place.
Looking at other tests today I spotted that rss flow label test is also
behaving oddly. Most of the time the first case fails and the second
passes:
test "rss-flow-label-py"
group "selftests-drivers-net-hw"
result "fail"
link "https://netdev-ci-results.intel.com/ice-results/net-next-hw-2026-06-26--00-00/ice-E810-XXV4/rss_flow_label.py/stdout"
results
0
test "rss-flow-label-test-rss-flow-label"
result "fail"
1
test "rss-flow-label-test-rss-flow-label-6only"
result "pass"
But every now and then they skip:
ok 1 rss_flow_label.test_rss_flow_label # SKIP Device doesn't support Flow Label for UDP6
ok 2 rss_flow_label.test_rss_flow_label_6only # SKIP Device doesn't support Flow Label for UDP6
test "rss-flow-label-py"
group "selftests-drivers-net-hw"
result "skip"
link "https://netdev-ci-results.intel.com/ice-results/net-next-hw-2026-06-25--16-00/ice-E810-XXV4/rss_flow_label.py/stdout"
results
0
test "rss-flow-label-test-rss-flow-label"
result "skip"
1
test "rss-flow-label-test-rss-flow-label-6only"
result "skip"
The devlink info is identical so it must be that the device
is in unclean state sometimes?? Do y'all power cycle these
machines between runs?
^ 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