Netdev List
 help / color / mirror / Atom feed
* [mellanox/mlx5-next RFC 1/1] net/mlx5: RX, Fix refcount warning on frag page release
From: Nabil S. Alramli @ 2026-06-25 17:40 UTC (permalink / raw)
  To: saeedm, tariqt, mbloch, dtatulea
  Cc: dev, nalramli, leon, andrew+netdev, davem, edumazet, kuba, pabeni,
	netdev, linux-rdma, linux-kernel

Hello mlx5 experts,

We have been experiencing frequent WARNINGs in the mlx5 driver on frag page
release and we think it could possibly be caused by a bug in mlx5. Could
you please review the attached patch and provide us your guidance on
whether or not our investigation and assumptions are valid, and if so,
would it be possible to incorporate this fix into your next release?

Best Regards,

Nabil S. Alramli (1):
  net/mlx5: RX, Fix refcount warning on frag page release

 drivers/net/ethernet/mellanox/mlx5/core/en.h  |  2 +-
 .../net/ethernet/mellanox/mlx5/core/en_main.c |  2 +-
 .../net/ethernet/mellanox/mlx5/core/en_rx.c   | 39 ++++++++++---------
 3 files changed, 22 insertions(+), 21 deletions(-)

-- 
2.43.0


^ permalink raw reply

* [mellanox/mlx5-next RFC 1/1] net/mlx5: RX, Fix refcount warning on frag page release
From: Nabil S. Alramli @ 2026-06-25 17:40 UTC (permalink / raw)
  To: saeedm, tariqt, mbloch, dtatulea
  Cc: dev, nalramli, leon, andrew+netdev, davem, edumazet, kuba, pabeni,
	netdev, linux-rdma, linux-kernel
In-Reply-To: <20260625174059.2879717-1-dev@nalramli.com>

Under memory pressure, mlx5 driver has WARNING during fragmented page
release. This happens because there is a discrepency between what mlx5
thinks the page fragment counter is vs what the page_pool actually says it
is.

The cause of the issue is page allocations on concurrent cpus, which
increment the non-atomic u16 page counter mlx5e_frag_page.frags, while at
the same time the page reference counter net_iov.pp_ref_count is atomically
incremented. That sometimes leads to a difference in the counts and
therefore triggers the warning in page_pool_unref_netmem:

```
	ret = atomic_long_sub_return(nr, pp_ref_count);
	WARN_ON(ret < 0);
```

The actual stack trace looks like this:

```
WARNING: CPU: 37 PID: 447795 at include/net/page_pool/helpers.h:277 mlx5e_page_release_fragmented.isra.0+0x51/0x60 [mlx5_core]
Tainted: [S]=CPU_OUT_OF_SPEC, [O]=OOT_MODULE
Hardware name: *
RIP: 0010:mlx5e_page_release_fragmented.isra.0+0x51/0x60 [mlx5_core]
RSP: 0018:ffffc90019814d98 EFLAGS: 00010293
RAX: 000000000000003f RBX: ffff88c0993d0a10 RCX: ffffea02424592c0
RDX: 0000000000000001 RSI: ffffea02424592c0 RDI: ffff88c090e20000
RBP: 000000000000000a R08: 0000000000001409 R09: 0000000000000006
R10: 0000000000000000 R11: ffff88c095fbc040 R12: 000000000000141f
R13: 0000000000000009 R14: ffff88c090e20000 R15: 0000000000000001
FS:  00007f34149fa6c0(0000) GS:ffff89200fa40000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ed0265eb000 CR3: 0000005091cbe000 CR4: 0000000000350ef0
Call Trace:
 <IRQ>
 mlx5e_free_rx_wqes+0x7b/0xa0 [mlx5_core]
 mlx5e_post_rx_wqes+0x1ac/0x5a0 [mlx5_core]
 mlx5e_napi_poll+0x5e5/0x6f0 [mlx5_core]
 __napi_poll+0x2b/0x1a0
 net_rx_action+0x30e/0x370
 ? sched_clock+0x9/0x10
 ? sched_clock_cpu+0xf/0x170
 handle_softirqs+0xe2/0x2a0
 common_interrupt+0x85/0xa0
 </IRQ>
 <TASK>
 asm_common_interrupt+0x26/0x40
RIP: 0010:page_counter_uncharge+0x34/0x90
RSP: 0018:ffffc900e728bb00 EFLAGS: 00000213
RAX: ffff88aff4762000 RBX: ffff88aff4762100 RCX: 0000000000000304
RDX: 0000000000000001 RSI: 00000000004e9e1a RDI: ffff88aff4762100
RBP: 0000000000000001 R08: ffff891ea0560048 R09: 00007ffffffff000
R10: 0000000000001000 R11: ffff891ae8061b00 R12: ffffffffffffffff
R13: ffff89107fcfd4c0 R14: ffff891ae8061b00 R15: ffff892002fe1400
 uncharge_batch+0x40/0xd0
```

The fix is to use an atomic page fragment counter, so it will always match
the number of references held in the page_pool.

Signed-off-by: Nabil S. Alramli <dev@nalramli.com>
Fixes: 6f5742846053 ("net/mlx5e: RX, Enable skb page recycling through the page_pool")
---
 drivers/net/ethernet/mellanox/mlx5/core/en.h  |  2 +-
 .../net/ethernet/mellanox/mlx5/core/en_main.c |  2 +-
 .../net/ethernet/mellanox/mlx5/core/en_rx.c   | 39 ++++++++++---------
 3 files changed, 22 insertions(+), 21 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en.h b/drivers/net/ethernet/mellanox/mlx5/core/en.h
index 2270e2e550dd..c164106eb85d 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en.h
@@ -568,7 +568,7 @@ struct mlx5e_icosq {
 
 struct mlx5e_frag_page {
 	netmem_ref netmem;
-	u16 frags;
+	atomic_long_t frags;
 };
 
 enum mlx5e_wqe_frag_flag {
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 5a46870c4b74..571a0df9f604 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -400,7 +400,7 @@ static int mlx5e_rq_alloc_mpwqe_linear_info(struct mlx5e_rq *rq, int node,
 	rq->mpwqe.linear_info = li;
 
 	/* Set to max to force allocation on first run. */
-	li->frag_page.frags = li->max_frags;
+	atomic_long_set(&li->frag_page.frags, li->max_frags);
 
 	return 0;
 }
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
index 5b60aa47c75b..ee360fa0c316 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_rx.c
@@ -284,7 +284,7 @@ static int mlx5e_page_alloc_fragmented(struct page_pool *pp,
 
 	*frag_page = (struct mlx5e_frag_page) {
 		.netmem	= netmem,
-		.frags	= 0,
+		.frags	= ATOMIC_LONG_INIT(0),
 	};
 
 	return 0;
@@ -293,7 +293,7 @@ static int mlx5e_page_alloc_fragmented(struct page_pool *pp,
 static void mlx5e_page_release_fragmented(struct page_pool *pp,
 					  struct mlx5e_frag_page *frag_page)
 {
-	u16 drain_count = MLX5E_PAGECNT_BIAS_MAX - frag_page->frags;
+	u16 drain_count = MLX5E_PAGECNT_BIAS_MAX - atomic_long_read(&frag_page->frags);
 	netmem_ref netmem = frag_page->netmem;
 
 	if (page_pool_unref_netmem(netmem, drain_count) == 0)
@@ -304,7 +304,7 @@ static int mlx5e_mpwqe_linear_page_refill(struct mlx5e_rq *rq)
 {
 	struct mlx5e_mpw_linear_info *li = rq->mpwqe.linear_info;
 
-	if (likely(li->frag_page.frags < li->max_frags))
+	if (likely(atomic_long_read(&li->frag_page.frags) < li->max_frags))
 		return 0;
 
 	if (likely(li->frag_page.netmem)) {
@@ -323,7 +323,8 @@ static void *mlx5e_mpwqe_get_linear_page_frag(struct mlx5e_rq *rq)
 	if (unlikely(mlx5e_mpwqe_linear_page_refill(rq)))
 		return NULL;
 
-	frag_offset = li->frag_page.frags << MLX5E_XDP_LOG_MAX_LINEAR_SZ;
+	frag_offset = atomic_long_read(&li->frag_page.frags) <<
+		      MLX5E_XDP_LOG_MAX_LINEAR_SZ;
 	WARN_ON(frag_offset >= BIT(rq->mpwqe.page_shift));
 
 	return netmem_address(li->frag_page.netmem) + frag_offset;
@@ -568,7 +569,7 @@ mlx5e_add_skb_frag(struct mlx5e_rq *rq, struct sk_buff *skb,
 		return;
 	}
 
-	frag_page->frags++;
+	atomic_long_inc(&frag_page->frags);
 	skb_add_rx_frag_netmem(skb, next_frag, netmem,
 			       frag_offset, len, truesize);
 }
@@ -744,7 +745,7 @@ void mlx5e_mpwqe_dealloc_linear_page(struct mlx5e_rq *rq)
 	 * things in a good state for re-allocation.
 	 */
 	li->frag_page.netmem = 0;
-	li->frag_page.frags = li->max_frags;
+	atomic_long_set(&li->frag_page.frags, li->max_frags);
 }
 
 INDIRECT_CALLABLE_SCOPE bool mlx5e_post_rx_wqes(struct mlx5e_rq *rq)
@@ -1615,7 +1616,7 @@ mlx5e_skb_from_cqe_linear(struct mlx5e_rq *rq, struct mlx5e_wqe_frag_info *wi,
 
 	/* queue up for recycling/reuse */
 	skb_mark_for_recycle(skb);
-	frag_page->frags++;
+	atomic_long_inc(&frag_page->frags);
 
 	return skb;
 }
@@ -1683,7 +1684,7 @@ mlx5e_skb_from_cqe_nonlinear(struct mlx5e_rq *rq, struct mlx5e_wqe_frag_info *wi
 				struct mlx5e_wqe_frag_info *pwi;
 
 				for (pwi = head_wi; pwi < wi; pwi++)
-					pwi->frag_page->frags++;
+					atomic_long_inc(&pwi->frag_page->frags);
 			}
 			return NULL; /* page/packet was consumed by XDP */
 		}
@@ -1702,7 +1703,7 @@ mlx5e_skb_from_cqe_nonlinear(struct mlx5e_rq *rq, struct mlx5e_wqe_frag_info *wi
 		return NULL;
 
 	skb_mark_for_recycle(skb);
-	head_wi->frag_page->frags++;
+	atomic_long_inc(&head_wi->frag_page->frags);
 
 	if (xdp_buff_has_frags(&mxbuf->xdp)) {
 		/* sinfo->nr_frags is reset by build_skb, calculate again. */
@@ -1711,7 +1712,7 @@ mlx5e_skb_from_cqe_nonlinear(struct mlx5e_rq *rq, struct mlx5e_wqe_frag_info *wi
 					  xdp_buff_get_skb_flags(&mxbuf->xdp));
 
 		for (struct mlx5e_wqe_frag_info *pwi = head_wi + 1; pwi < wi; pwi++)
-			pwi->frag_page->frags++;
+			atomic_long_inc(&pwi->frag_page->frags);
 	}
 
 	return skb;
@@ -1760,7 +1761,7 @@ static void mlx5e_handle_rx_cqe(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe)
 	if (!skb) {
 		/* probably for XDP */
 		if (__test_and_clear_bit(MLX5E_RQ_FLAG_XDP_XMIT, rq->flags))
-			wi->frag_page->frags++;
+			atomic_long_inc(&wi->frag_page->frags);
 		goto wq_cyc_pop;
 	}
 
@@ -1808,7 +1809,7 @@ static void mlx5e_handle_rx_cqe_rep(struct mlx5e_rq *rq, struct mlx5_cqe64 *cqe)
 	if (!skb) {
 		/* probably for XDP */
 		if (__test_and_clear_bit(MLX5E_RQ_FLAG_XDP_XMIT, rq->flags))
-			wi->frag_page->frags++;
+			atomic_long_inc(&wi->frag_page->frags);
 		goto wq_cyc_pop;
 	}
 
@@ -2011,9 +2012,9 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w
 				struct mlx5e_frag_page *pfp;
 
 				for (pfp = head_page; pfp < frag_page; pfp++)
-					pfp->frags++;
+					atomic_long_inc(&pfp->frags);
 
-				linear_page->frags++;
+				atomic_long_inc(&linear_page->frags);
 			}
 			return NULL; /* page/packet was consumed by XDP */
 		}
@@ -2035,7 +2036,7 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w
 			return NULL;
 
 		skb_mark_for_recycle(skb);
-		linear_page->frags++;
+		atomic_long_inc(&linear_page->frags);
 
 		if (xdp_buff_has_frags(&mxbuf->xdp)) {
 			struct mlx5e_frag_page *pagep;
@@ -2048,7 +2049,7 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w
 
 			pagep = head_page;
 			do
-				pagep->frags++;
+				atomic_long_inc(&pagep->frags);
 			while (++pagep < frag_page);
 
 			headlen = min_t(u16, MLX5E_RX_MAX_HEAD - len,
@@ -2068,7 +2069,7 @@ mlx5e_skb_from_cqe_mpwrq_nonlinear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *w
 
 			pagep = frag_page - sinfo->nr_frags;
 			do
-				pagep->frags++;
+				atomic_long_inc(&pagep->frags);
 			while (++pagep < frag_page);
 		}
 		/* copy header */
@@ -2121,7 +2122,7 @@ mlx5e_skb_from_cqe_mpwrq_linear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *wi,
 				 cqe_bcnt, mxbuf);
 		if (mlx5e_xdp_handle(rq, prog, mxbuf)) {
 			if (__test_and_clear_bit(MLX5E_RQ_FLAG_XDP_XMIT, rq->flags))
-				frag_page->frags++;
+				atomic_long_inc(&frag_page->frags);
 			return NULL; /* page/packet was consumed by XDP */
 		}
 
@@ -2136,7 +2137,7 @@ mlx5e_skb_from_cqe_mpwrq_linear(struct mlx5e_rq *rq, struct mlx5e_mpw_info *wi,
 
 	/* queue up for recycling/reuse */
 	skb_mark_for_recycle(skb);
-	frag_page->frags++;
+	atomic_long_inc(&frag_page->frags);
 
 	return skb;
 }
-- 
2.43.0


^ permalink raw reply related

* Re: [PATCH net v2] seg6: validate SRH length before reading fixed fields
From: Andrea Mayer @ 2026-06-25 19:49 UTC (permalink / raw)
  To: Nuoqi Gui
  Cc: David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
	Simon Horman, netdev, bpf, linux-kernel, Mathieu Xhonneux,
	Daniel Borkmann, David Lebrun, stefano.salsano, Paolo Lungaroni,
	Andrea Mayer
In-Reply-To: <20260623-f01-17-seg6-srh-len-v2-1-2edc40e9e3e1@mails.tsinghua.edu.cn>

On Tue, 23 Jun 2026 18:32:31 +0800
Nuoqi Gui <gnq25@mails.tsinghua.edu.cn> wrote:

> seg6_validate_srh() reads fixed SRH fields such as srh->type and
> srh->hdrlen before checking that the supplied length covers the fixed
> struct ipv6_sr_hdr fields.
> 
> The BPF SEG6 encap path reaches this with a BPF program-supplied pointer
> and length: bpf_lwt_push_encap() and the SEG6 local BPF END_B6 and
> END_B6_ENCAP actions call bpf_push_seg6_encap(), which forwards the
> length to seg6_validate_srh() with no minimum-size guard.  A 2-byte SEG6
> encap header can therefore make the validator read srh->type at offset 2
> beyond the caller-supplied buffer.
> 
> Reject lengths shorter than the fixed SRH at the top of
> seg6_validate_srh(), before any field is read.  This fixes the BPF helper
> path and keeps the common validator robust.
> 
> Fixes: fe94cc290f53 ("bpf: Add IPv6 Segment Routing helpers")
> Signed-off-by: Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
> ---
> Changes in v2:
> - Narrowed the commit message to the BPF encap callers that can supply a
>   too-short SRH length.
> - Dropped the unnecessary cast in the minimum SRH length check.
> - Link to v1: https://patch.msgid.link/20260620-f01-17-seg6-srh-len-v1-1-36cbb29c12f1@mails.tsinghua.edu.cn  
> 
> To: Andrea Mayer <andrea.mayer@uniroma2.it>
> To: "David S. Miller" <davem@davemloft.net>
> To: Eric Dumazet <edumazet@google.com>
> To: Jakub Kicinski <kuba@kernel.org>
> To: Paolo Abeni <pabeni@redhat.com>
> To: Simon Horman <horms@kernel.org>
> To: Mathieu Xhonneux <m.xhonneux@gmail.com>
> To: Daniel Borkmann <daniel@iogearbox.net>
> To: David Lebrun <dlebrun@google.com>
> Cc: netdev@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: bpf@vger.kernel.org
> ---
>  net/ipv6/seg6.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/net/ipv6/seg6.c b/net/ipv6/seg6.c
> index 1c3ad25700c4c..62a7eb7792026 100644
> --- a/net/ipv6/seg6.c
> +++ b/net/ipv6/seg6.c
> @@ -29,6 +29,9 @@ bool seg6_validate_srh(struct ipv6_sr_hdr *srh, int len, bool reduced)
>  	int max_last_entry;
>  	int trailing;
>  
> +	if (len < sizeof(*srh))
> +		return false;
> +

Thanks for the patch.

Looks good to me.

Reviewed-by: Andrea Mayer <andrea.mayer@uniroma2.it>

On a separate note: the AI review message seems correct. The reported
issue is a separate, pre-existing bug in the BPF SEG6 encap path, not
introduced by this patch.

Regards,
Andrea

>  	if (srh->type != IPV6_SRCRT_TYPE_4)
>  		return false;
>  
> 
> ---
> base-commit: 96e7f9122aae0ed000ee321f324b812a447906d9
> change-id: 20260619-f01-17-seg6-srh-len-a85f35427e0b
> 
> Best regards,
> --  
> Nuoqi Gui <gnq25@mails.tsinghua.edu.cn>
> 

^ permalink raw reply

* Re: [PATCH bpf-next v2 1/4] bpf: Initialize the l3mdev field for the fib lookup flow
From: David Ahern @ 2026-06-25 19:51 UTC (permalink / raw)
  To: Toke Høiland-Jørgensen, Avinash Duduskar,
	Alexei Starovoitov, Daniel Borkmann, Andrii Nakryiko
  Cc: Eduard Zingerman, Kumar Kartikeya Dwivedi, Martin KaFai Lau,
	Song Liu, Yonghong Song, Jiri Olsa, Emil Tsalapatis,
	John Fastabend, Stanislav Fomichev, David S. Miller, Eric Dumazet,
	Jakub Kicinski, Paolo Abeni, Simon Horman, Shuah Khan,
	Jesper Dangaard Brouer, Mykyta Yatsenko, Leon Hwang, KP Singh,
	Anton Protopopov, Amery Hung, Eyal Birger, Rong Tao, bpf, netdev,
	linux-kselftest, linux-kernel
In-Reply-To: <87bjd9h6yh.fsf@toke.dk>

On 6/17/26 3:06 AM, Toke Høiland-Jørgensen wrote:
>> The helper already initializes the other flow fields the rules path
>> consumes (flowi4_mark, flowi4_tun_key.tun_id, flowi4_uid and the v6
>> counterparts); flowi*_l3mdev was added to that set afterwards and this
>> helper was never updated to match. ip_route_input_slow() likewise zeroes
>> the field before its input lookup. Do the same here.
> 
> So how about we explicitly zero-init the whole struct instead of adding
> more fields ad-hoc like this? Otherwise this seems like something that
> is likely to happen again if we ever add another field to the struct?
> 
> -Toke
> 

+1. Piecemeal init of the flow struct has been a known source of bugs.

^ permalink raw reply

* Re: [GIT PULL] Networking for v7.2-rc1
From: pr-tracker-bot @ 2026-06-25 19:57 UTC (permalink / raw)
  To: Jakub Kicinski; +Cc: torvalds, kuba, davem, netdev, linux-kernel, pabeni
In-Reply-To: <20260625174511.745883-1-kuba@kernel.org>

The pull request you sent on Thu, 25 Jun 2026 10:45:11 -0700:

> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git tags/net-7.2-rc1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/805185b7c7a1069e407b6f7b3bc98e44d415f484

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

^ permalink raw reply

* Re: [PATCH v29 4/5] sfc: obtain and map cxl range using devm_cxl_probe_mem
From: Dan Williams (nvidia) @ 2026-06-25 20:34 UTC (permalink / raw)
  To: Alejandro Lucero Palau, Dan Williams (nvidia),
	alejandro.lucero-palau, linux-cxl, netdev, dan.j.williams,
	edward.cree, davem, kuba, pabeni, edumazet, dave.jiang
  Cc: Edward Cree
In-Reply-To: <b0a45e85-f42c-4a52-8223-f8318da10649@amd.com>

Alejandro Lucero Palau wrote:
[..]
> >> +{
> > If you are going to have an explicit efx_cxl_exit() then I would also
> > add an explicit unregistration of the memdev.
> 
> 
> This is necessary for undoing the mmap. Nothing else happens there 
> because it is all relying on devm ...
> 
> 
> I could change the ioremap_wc call to devm_ioremap_wc, but
> 
> 
> > This would also fix the
> > Sashiko report about pci_disable_device() running while the cxl_memdev
> > is still registered. Unfortunately, mixing devm and explicit unwind is
> > always fraught.
> 
> 
> I do not think there is a problem here. The cxl core does not need what 
> a type2 driver can do regarding PCI BAR mappings, or at least it is not 
> the case for sfc.
> 
> Any action through sysfs cxl will go through cxl core and the only thing 
> linked to the type device is the CXL registers which are mapped inside 
> cxl_map_component_regs() and those are managed resources.
> 
> 
> So, I can not see why this change is needed. If it is really necessary, 
> please describe the problem with more detail.
> 
> 
> It looks like you need reasons for delaying this further ...

What? Help with Sashiko reports is an act of malice? I assumed you
wanted help with those so that other maintainers would proceed with
these patches. 

I did do another run through to see if there are any paths that the CXL
core can reach if someone tried to fuzz the CXL ABIs or kernel paths
while SFC is unloading. I think Sashiko is hallucinating a sysfs path to
the BAR mapping given there is no mailbox and the EDAC capabilities are
usually not present on a type-2 device. The RAS path looks valid, but
that may also get lucky that most (all?) of the RAS use cases lock the
device before accessing the registers, so devres_release_all() would
become consistent with pci_disable_device() before any access attempt.
That does not seem like a clean design, but it is also does not appear
to be immediately exploitable.

If you believe the patches are ready and the Sashiko reports are
invalid, please do say so, no more comments from me on this set from
this point forward.

> > Let me know if this passes your testing, and I can send it out as a
> > standalone patch. You could also use it to unwind if the ioremap()
> > fails.
> 
> 
> You did not read my comments on v28 ...
> 
> 
> I changed efx_cxl_init to make the driver probe to fail if cxl is 
> supported and enabled but the cxl initialization fails, including 
> ioremap_wc(). What you proposed to do, explicitly undo cxl 
> initialization bits, has the same outcome: device detached from the driver.

Right, I did read that and that motivated the devm_cxl_remove_mem()
helper to undo the memdev creation without unloading the driver. You are
free to ignore that helper.

^ permalink raw reply

* Re: [PATCH net] octeontx2-pf: check DMAC extraction support before filtering
From: Harshitha Ramamurthy @ 2026-06-25 21:28 UTC (permalink / raw)
  To: nshettyj
  Cc: netdev, linux-kernel, sgoutham, gakula, sbhatta, hkelam,
	bbhushan2, andrew+netdev, davem, edumazet, kuba, pabeni, naveenm,
	tduszynski, sumang
In-Reply-To: <20260625172552.258631-1-nshettyj@marvell.com>

On Thu, Jun 25, 2026 at 10:30 AM <nshettyj@marvell.com> wrote:
>
> 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>
> ---
>  .../ethernet/marvell/octeontx2/nic/otx2_pf.c  | 34 +++++++++++++++++++
>  1 file changed, 34 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..8e4435d9e520 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/nic/otx2_pf.c
> @@ -2546,6 +2546,8 @@ static int otx2_do_set_vf_mac(struct otx2_nic *pf, int vf, const u8 *mac)
>  static int otx2_set_vf_mac(struct net_device *netdev, int vf, u8 *mac)
>  {
>         struct otx2_nic *pf = netdev_priv(netdev);
> +       struct npc_get_field_status_req *req;
> +       struct npc_get_field_status_rsp *rsp;
>         struct pci_dev *pdev = pf->pdev;
>         struct otx2_vf_config *config;
>         int ret;
> @@ -2559,6 +2561,38 @@ static int otx2_set_vf_mac(struct net_device *netdev, int vf, u8 *mac)
>         if (!is_valid_ether_addr(mac))
>                 return -EINVAL;
>
> +       /* Skip installing the DMAC filter if the hardware parser profile
> +        * does not support DMAC extraction.
> +        */
> +       mutex_lock(&pf->mbox.lock);
> +       req = otx2_mbox_alloc_msg_npc_get_field_status(&pf->mbox);
> +       if (!req) {
> +               mutex_unlock(&pf->mbox.lock);
> +               return -ENOMEM;
> +       }
> +
> +       req->field = NPC_DMAC;
> +       if (otx2_sync_mbox_msg(&pf->mbox)) {
> +               mutex_unlock(&pf->mbox.lock);
> +               return -EINVAL;
> +       }
> +
> +       rsp = (struct npc_get_field_status_rsp *)otx2_mbox_get_rsp
> +              (&pf->mbox.mbox, 0, &req->hdr);
> +       if (IS_ERR(rsp)) {
> +               mutex_unlock(&pf->mbox.lock);
> +               return PTR_ERR(rsp);
> +       }
> +
> +       if (!rsp->enable) {
> +               mutex_unlock(&pf->mbox.lock);
> +               netdev_warn(netdev, "VF %d MAC filter not installed: DMAC extraction not supported by parser profile\n",
> +                           vf);
> +               return 0;

Is the intent to return success here even though the MAC address was
not programmed?

> +       }
> +
> +       mutex_unlock(&pf->mbox.lock);
> +

Why not move all these checks into the otx2_do_set_vf_mac() since that
anyway acquires the pf->mbox.lock? That way you could also fold all
the mutex_unlock() calls introduced in the error paths in this patch
into the existing goto-out in that function.

>         config = &pf->vf_configs[vf];
>         ether_addr_copy(config->mac, mac);
>
> --
> 2.48.1
>
>

^ permalink raw reply

* Re: [PATCH iproute2-next] "ip help" wrong output, exit code.
From: Stephen Hemminger @ 2026-06-25 21:34 UTC (permalink / raw)
  To: Dmitri Seletski; +Cc: netdev
In-Reply-To: <65f53987-c992-41b9-9603-9e9a448e469d@gmail.com>

On Thu, 25 Jun 2026 16:54:29 +0100
Dmitri Seletski <drjoms@gmail.com> wrote:

> I am confused.
> 
> Whats the next step here?
> 
> Regards
> 
> Dmitri
> 
> On 6/22/26 18:47, Dmitri Seletski wrote:
> > Hello David,
> >
> >
> > Based on change introduced:
> >
> > Two samples of "ip help" with demonstration of exit code and standard 
> > output are below.
> >
> > This is in line with what expect.
> >
> >
> > dimkosPC~/compiled/iproute2-next #if ./ip/ip help a >>/dev/null  ; 
> > then echo help triggered  ; else echo error code triggered  ;fi  #this 
> > redirects standard output  to /dev/null, so text missing is not error,
> > but standard text
> > help triggered
> >
> > dimkosPC~/compiled/iproute2-next #if ./ip/ip help   ; then echo help 
> > triggered  ; else echo error code triggered  ;fi
> > Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }
> >       ip [ -force ] -batch filename
> > where  OBJECT := { address | addrlabel | fou | help | ila | ioam | 
> > l2tp | link |
> >                   macsec | maddress | monitor | mptcp | mroute | mrule |
> >                   neighbor | neighbour | netconf | netns | nexthop | 
> > ntable |
> >                   ntbl | route | rule | sr | stats | tap | tcpmetrics |
> >                   token | tunnel | tuntap | vrf | xfrm }
> >       OPTIONS := { -V[ersion] | -s[tatistics] | -d[etails] | -r[esolve] |
> >                    -h[uman-readable] | -iec | -j[son] | -p[retty] |
> >                    -f[amily] { inet | inet6 | mpls | bridge | link } |
> >                    -4 | -6 | -M | -B | -0 |
> >                    -l[oops] { maximum-addr-flush-attempts } | -echo | 
> > -br[ief] |
> >                    -o[neline] | -t[imestamp] | -ts[hort] | -b[atch] 
> > [filename] |
> >                    -rc[vbuf] [size] | -n[etns] name | -N[umeric] | 
> > -a[ll] |
> >                    -c[olor]}
> > help triggered
> >
> > Two samples of command that is broken on purpose.
> >
> > dimkosPC~/compiled/iproute2-next #if ./ip/ip idontexist   ; then echo 
> > help triggered  ; else echo error code triggered  ;fi
> > Object "idontexist" is unknown, try "ip help".
> > error code triggered
> >
> > dimkosPC~/compiled/iproute2-next #if ./ip/ip idontexist  >>/dev/null 
> >  ; then echo help triggered  ; else echo error code triggered  ;fi 
> >  #this redirects standard output  to /dev/null, so text missing is not 
> > error, but standard text
> > Object "idontexist" is unknown, try "ip help".
> > error code triggered
> >
> > This works as expected as per my understanding.
> >
> >
> > Not everything is fixed, but chunk of things fixed is better than non 
> > of it.
> >
> > for example:
> >
> > if ip  add help    ; then echo help triggered  ; else echo error code 
> > triggered  ;fi  #this redirects standard output  to /dev/null, so text 
> > missing is not error, but standard text
> > Usage: ip address {add|change|replace} IFADDR dev IFNAME [ LIFETIME ]
> >                                                      [ CONFFLAG-LIST ]
> >       ip address del IFADDR dev IFNAME [mngtmpaddr]
> >       ip address {save|flush} [ dev IFNAME ] [ scope SCOPE-ID ] [ to 
> > PREFIX ]
> >                            [ FLAG-LIST ] [ label LABEL ] [ { up | down 
> > } ]
> >       ip address [ show [ dev IFNAME ] [ scope SCOPE-ID ] [ master 
> > DEVICE ]
> >                         [ nomaster ]
> >                         [ type TYPE ] [ to PREFIX ] [ FLAG-LIST ]
> >                         [ label LABEL ] [ { up | down } ] [ vrf NAME ]
> >                         [ proto ADDRPROTO ] ]
> >       ip address {showdump|restore}
> > IFADDR := PREFIX | ADDR peer PREFIX
> >          [ broadcast ADDR ] [ anycast ADDR ]
> >          [ label IFNAME ] [ scope SCOPE-ID ] [ metric METRIC ]
> >          [ proto ADDRPROTO ]
> > SCOPE-ID := [ host | link | global | NUMBER ]
> > FLAG-LIST := [ FLAG-LIST ] FLAG
> > FLAG  := [ permanent | dynamic | secondary | primary |
> >           [-]tentative | [-]deprecated | [-]dadfailed | temporary |
> >           CONFFLAG-LIST ]
> > CONFFLAG-LIST := [ CONFFLAG-LIST ] CONFFLAG
> > CONFFLAG  := [ home | nodad | mngtmpaddr | noprefixroute | autojoin ]
> > LIFETIME := [ valid_lft LFT ] [ preferred_lft LFT ]
> > LFT := forever | SECONDS
> > ADDRPROTO := [ NAME | NUMBER ]
> > TYPE := { amt | bareudp | bond | bond_slave | bridge | bridge_slave |
> >          dsa | dummy | erspan | geneve | gre | gretap | gtp | hsr |
> >          ifb | ip6erspan | ip6gre | ip6gretap | ip6tnl |
> >          ipip | ipoib | ipvlan | ipvtap |
> >          macsec | macvlan | macvtap | netdevsim |
> >          netkit | nlmon | pfcp | rmnet | sit | team | team_slave |
> >          vcan | veth | vlan | vrf | vti | vxcan | vxlan | wwan |
> >          xfrm | virt_wifi }
> > error code triggered
> >
> > This is still problematic.
> >
> >
> > But so far code leaves "ip help" command/argument in better shape than 
> > it found it in.
> >
> >
> > I may try improve things more, but lets submit what we already have 
> > "better", please.
> >
> > Kind Regards
> >
> > Dmitri Seletski
> >
> >
> > On 6/22/26 17:44, David Laight wrote:  
> >> On Mon, 22 Jun 2026 07:57:00 -0700
> >> Stephen Hemminger <stephen@networkplumber.org> wrote:
> >>  
> >>> On Sun, 21 Jun 2026 22:48:59 +0100
> >>> Dmitri Seletski <drjoms@gmail.com> wrote:
> >>>  
> >>>>  From 0805e07105cd15c5b94271a4706e50e3c65dbde5 Mon Sep 17 00:00:00 
> >>>> 2001
> >>>> From: Dmitri Seletski <drjoms@gmail.com>
> >>>> Date: Sun, 21 Jun 2026 22:12:43 +0100
> >>>> Subject: [PATCH iproute2-next]  "ip help" wrong output, exit code.
> >>>>
> >>>> Changed output of "ip help" from standard error to standard output. 
> >>>> And
> >>>> Exit is now 0 instead of -1. "ip help|grep bridge" - now gives bridge
> >>>> syntax instead of flooding user with everything from "ip help".
> >>>> ---
> >>>> ip/ip.c | 4 ++--
> >>>> 1 file changed, 2 insertions(+), 2 deletions(-)
> >>>>
> >>>> diff --git a/ip/ip.c b/ip/ip.c
> >>>> index e4b71bde..4627b61c 100644
> >>>> --- a/ip/ip.c
> >>>> +++ b/ip/ip.c
> >>>> @@ -56,7 +56,7 @@ static void usage(void) __attribute__((noreturn));
> >>>>
> >>>> static void usage(void)
> >>>> {
> >>>> -fprintf(stderr,
> >>>> +fprintf(stdout,
> >>>> "Usage: ip [ OPTIONS ] OBJECT { COMMAND | help }\n"
> >>>> "       ip [ -force ] -batch filename\n"
> >>>> "where  OBJECT := { address | addrlabel | fou | help | ila | ioam | 
> >>>> l2tp
> >>>> | link |\n"
> >>>> @@ -72,7 +72,7 @@ static void usage(void)
> >>>> "                    -o[neline] | -t[imestamp] | -ts[hort] | -b[atch]
> >>>> [filename] |\n"
> >>>> "                    -rc[vbuf] [size] | -n[etns] name | -N[umeric] |
> >>>> -a[ll] |\n"
> >>>> "                    -c[olor]}\n");
> >>>> -exit(-1);
> >>>> +exit(0);
> >>>> }  
> >>> Your mailer damages white space.
> >>>  
> >> The output also needs to depend on whether these is a 'usage' error or
> >> if 'help' is requested.
> >> Code code is correct for the former - except it should do exit(1).
> >>
> >>     David
> >>
> >>  
> 

We need to have a broad solution that doesn't look ugly.
There are a couple problems with current code:
  1. Help should exit with 0 (ok); invalid argument should exit with non-zero
     by Gnu convention that is 2 but other commands like git use 129
  2. help should go to stdout; usage on error should go to stderr

The solution should work across iproute2 commands: ip, tc, dpll, tipc, bridge, ...
and the sub commands.

So far the mailing list patches were kind of messy and limited.

^ permalink raw reply

* Re: [PATCH net-next] net: neigh: avoid calling neigh_forced_gc on every alloc when table is full
From: Kuniyuki Iwashima @ 2026-06-25 21:45 UTC (permalink / raw)
  To: avimalin; +Cc: edumazet, kuniyu, netdev, vimal.agrawal, kuba
In-Reply-To: <20260625102020.92814-1-vimal.agrawal@sophos.com>

From: Vimal Agrawal <avimalin@gmail.com>
Date: Thu, 25 Jun 2026 10:20:20 +0000
> Once the neighbour table exceeds gc_thresh3, neigh_forced_gc() is called
> on every allocation attempt with no rate limiting. In workloads with mostly
> active/reachable entries, the GC walk traverses a large portion of the
> neighbour table without reclaiming entries, holding tbl->lock for an
> extended period. This causes severe lock contention and allocation
> latencies exceeding 16ms under sustained neighbour creation.
> 
> Add a pre-lock check in neigh_forced_gc() to skip the GC run if one was
> performed within the last second, avoiding repeated full table scans and
> lock acquisitions on the hot allocation path.
> 
> Profiling of neigh_create() shows ~3 orders of magnitude latency
> improvement with this change.
> 
> Link:https://lore.kernel.org/netdev/CALkUMdSCpx_ywYCx_ePLdm6yioO1nQWx7sSM=AEgsq0kywHxTw@mail.gmail.com/

From the thread, these look misconfigured.

---8<---
net.ipv6.neigh.default.gc_thresh2 = 32768
net.ipv6.neigh.default.gc_thresh3 = 32768
---8<---

If gc_thresh3 is larger enough, gc_thresh2 will give you 5s
rate limiting.

If the number of active neigh entries constantly exceeds
gc_thresh3, it will be the correct gc_thresh2 for you.

Also, I guess you want a new kernel param for the first
neigh_hash_alloc(), which is currently fixed for 3, which
is too small for some hosts.

50000 entries require neigh_hash_grow() 13 times.

Can you test this on your real workload, starting from
neigh_hash_shift=16 and appropriate gc_thresh2/3 ?

---8<---
diff --git a/net/core/neighbour.c b/net/core/neighbour.c
index 1349c0eedb64..a75b3750eec9 100644
--- a/net/core/neighbour.c
+++ b/net/core/neighbour.c
@@ -1817,6 +1817,22 @@ EXPORT_SYMBOL(neigh_parms_release);
 static struct lock_class_key neigh_table_proxy_queue_class;
 
 static struct neigh_table __rcu *neigh_tables[NEIGH_NR_TABLES] __read_mostly;
+static __initdata unsigned long neigh_hash_shift = 3;
+
+static int __init neigh_set_hash_shift(char *str)
+{
+	ssize_t ret;
+
+	if (!str)
+		return 0;
+
+	ret = kstrtoul(str, 0, &neigh_hash_shift);
+	if (ret)
+		return 0;
+
+	return 1;
+}
+__setup("neigh_hash_shift=", neigh_set_hash_shift);
 
 void neigh_table_init(int index, struct neigh_table *tbl)
 {
@@ -1843,7 +1859,7 @@ void neigh_table_init(int index, struct neigh_table *tbl)
 		panic("cannot create neighbour proc dir entry");
 #endif
 
-	RCU_INIT_POINTER(tbl->nht, neigh_hash_alloc(3));
+	RCU_INIT_POINTER(tbl->nht, neigh_hash_alloc(neigh_hash_shift));
 
 	phsize = (PNEIGH_HASHMASK + 1) * sizeof(struct pneigh_entry *);
 	tbl->phash_buckets = kzalloc(phsize, GFP_KERNEL);
---8<---



> Signed-off-by: Vimal Agrawal <vimal.agrawal@sophos.com>
> ---
>  net/core/neighbour.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/net/core/neighbour.c b/net/core/neighbour.c
> index 1349c0eedb64..078842db3c5f 100644
> --- a/net/core/neighbour.c
> +++ b/net/core/neighbour.c
> @@ -260,6 +260,9 @@ static int neigh_forced_gc(struct neigh_table *tbl)
>  	int shrunk = 0;
>  	int loop = 0;
>  
> +	if (!time_after(jiffies, READ_ONCE(tbl->last_flush) + HZ))
> +		return 0;
> +
>  	NEIGH_CACHE_STAT_INC(tbl, forced_gc_runs);
>  
>  	spin_lock_bh(&tbl->lock);
> -- 
> 2.17.1
> v

^ permalink raw reply related

* Re: [PATCH v14 0/9] tls: Add TLS 1.3 hardware offload support
From: Rishikesh Jethwani @ 2026-06-25 22:57 UTC (permalink / raw)
  To: Nils Juenemann
  Cc: netdev, borisp, davem, edumazet, john.fastabend, kuba, leon,
	mbloch, saeedm, sd, tariqt
In-Reply-To: <CAMPsyauZ+jzG9AysO0FWv6ZY0kvCUpjX_U7o=oOjCuOQ87BCgg@mail.gmail.com>

On Tue, Jun 23, 2026 at 10:53 AM Nils Juenemann
<nils.juenemann@gmail.com> wrote:
>
> Hi Rishikesh, all,
>
> we have been testing the v14 TLS 1.3 HW offload series on a ConnectX-6
> DX and hit a sendfile() final-record loss on the device TX path. We
> reduced it to a self-contained C reproducer and characterized it;
> reporting it here with the analysis and a question on where a fix belongs.
>
> Setup:
>
> NIC: ConnectX-6 DX (crypto enabled), FW 22.47.1026, SR-IOV VF,
> TX offload only
>
> Kernel: net-next + this v14 series
>
> TLS 1.3, AES-128-GCM, kTLS installed via setsockopt(TLS_TX) on the
> sending side with fixed test crypto material and no handshake, like
> tools/testing/selftests/net/tls
>
> a server sends a file with the raw sendfile(2) syscall; a client on
> another host reads the decrypted stream and counts the bytes
>
> Trigger: sendfile(2) with a count larger than the bytes remaining in
> the file (count > EOF). This is what a generic copy loop / Go's
> net.TCPConn.ReadFrom passes for a file of unknown length (~2 GiB). The
> kernel sends up to EOF, but the connection's final TLS record then
> appears not to be put on the wire unless a subsequent write flushes it.
> An abrupt close() appears to drop it, and the peer receives the whole
> body except the last record's bytes.
>
> Reproducer results (two hosts over the ConnectX - a loopback/same-host
> connection stays on TLS_SW and does not show it). Same file, 226965
> bytes (= 13*16384 + 13973):
>
> TLS_HW count>EOF close() -> 212992 short
> TLS_HW count>EOF close(), no zerocopy -> 212992 same
> TLS_HW count==exact close() -> 226965 full
> TLS_HW count>EOF close_notify, then close() -> 226965 full
> TLS_SW count>EOF close(), hw-tx-offload off -> 226965 full
>
> So it is specific to the device-offload TX path: the final record of a
> count > EOF sendfile() appears not to be finalized/flushed at EOF, only
> by a following write. A bounded count, a trailing write (close_notify),
> or software kTLS all avoid it. TLS_TX_ZEROCOPY_RO makes no difference.
> We are currently using the exact-count workaround in a preview environment.
>
> We may be misreading the code, so this is only a pointer: with
> count > EOF tls_push_data() fills the last record without reaching the
> size==0 case; on the device path tls_device_record_close() for that
> pending record appears to run only on the next push, and an abrupt
> teardown appears to discard it. The software path seems to flush
> pending TX records on close (tls_sw_release_resources_tx), which would
> explain why it is unaffected.
>
> Reproducer:
> https://gist.github.com/totallyunknown/a8f0ad3c54e40befde2f5a8d360fa6be
>
> It installs kTLS with fixed test crypto material via
> setsockopt(TLS_TX/TLS_RX), sends a file using the raw sendfile(2)
> syscall, and compares count > EOF against exact-count and close_notify.
> The v14 selftest (patch 9/9) sends via send() only and ends cleanly, so
> it misses this; a sendfile() + count > EOF case reproduces it
> deterministically for us.
>
> Question: should the device offload finalize and flush the connection's
> final record at EOF / on close, the way software kTLS does, or is a
> trailing write required by contract? And should a fix live in net/tls
> (device record close on the final partial record / the close path) or
> on the mlx5 side?
>

close() should be sufficient here.
I will fix this in net/tls/tls_device.c:tls_device_splice_eof().
tls_device_splice_eof() only checked tls_is_partially_sent_record(),
but it also needs to handle tls_is_pending_open_record()
(pending_open_record_frags). On the device TX path, that state occurs
when tls_push_data() exits with MSG_MORE set, which is what
splice/sendfile does while count > EOF still leaves requested bytes
outstanding.
So EOF can be reached with a final open record still pending. The fix
is to close and push that record from tls_device_splice_eof(), so
close() remains sufficient and no trailing write is required.

^ permalink raw reply

* Re: [PATCH net] net: airoha: dma map xmit frags with skb_frag_dma_map()
From: Harshitha Ramamurthy @ 2026-06-25 22:59 UTC (permalink / raw)
  To: Lorenzo Bianconi
  Cc: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
	Paolo Abeni, linux-arm-kernel, linux-mediatek, netdev
In-Reply-To: <20260625-airoha-eth-skb_frag_dma_map-v1-1-31d9e460aae6@kernel.org>

On Thu, Jun 25, 2026 at 2:43 AM Lorenzo Bianconi <lorenzo@kernel.org> wrote:
>
> Map xmit skb fragments using skb_frag_dma_map() instead of
> dma_map_single(skb_frag_address()). skb_frag_address() relies on
> page_address() to obtain a kernel virtual address, which is not
> guaranteed to work for all page types (e.g. highmem pages or
> user-pinned pages from MSG_ZEROCOPY).
> skb_frag_dma_map() maps the fragment directly via its struct page and
> offset through dma_map_page(), avoiding the need for a kernel virtual
> address entirely.
> Introduce an enum airoha_dma_map_type to track how each queue entry was
> mapped (single vs page), so that the matching unmap function is called
> on completion and in error paths.
>
> Fixes: 23020f049327 ("net: airoha: Introduce ethernet support for EN7581 SoC")
> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>

Reviewed-by: Harshitha Ramamurthy <hramamurthy@google.com>

> ---
>  drivers/net/ethernet/airoha/airoha_eth.c | 61 ++++++++++++++++++++------------
>  drivers/net/ethernet/airoha/airoha_eth.h |  7 ++++
>  2 files changed, 45 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
> index 932b3a3df2e5..1caf6766f2c0 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.c
> +++ b/drivers/net/ethernet/airoha/airoha_eth.c
> @@ -944,6 +944,25 @@ static void airoha_qdma_wake_netdev_txqs(struct airoha_queue *q)
>         q->txq_stopped = false;
>  }
>
> +static void airoha_unmap_xmit_buf(struct airoha_eth *eth,
> +                                 struct airoha_queue_entry *e)
> +{
> +       switch (e->dma_type) {
> +       case AIROHA_DMA_MAP_PAGE:
> +               dma_unmap_page(eth->dev, e->dma_addr, e->dma_len,
> +                              DMA_TO_DEVICE);
> +               break;
> +       case AIROHA_DMA_MAP_SINGLE:
> +               dma_unmap_single(eth->dev, e->dma_addr, e->dma_len,
> +                                DMA_TO_DEVICE);
> +               break;
> +       case AIROHA_DMA_UNMAPPED:
> +       default:
> +               break;
> +       }
> +       e->dma_type = AIROHA_DMA_UNMAPPED;
> +}
> +
>  static int airoha_qdma_tx_napi_poll(struct napi_struct *napi, int budget)
>  {
>         struct airoha_tx_irq_queue *irq_q;
> @@ -1006,9 +1025,7 @@ static int airoha_qdma_tx_napi_poll(struct napi_struct *napi, int budget)
>                 skb = e->skb;
>                 e->skb = NULL;
>
> -               dma_unmap_single(eth->dev, e->dma_addr, e->dma_len,
> -                                DMA_TO_DEVICE);
> -               e->dma_addr = 0;
> +               airoha_unmap_xmit_buf(eth, e);
>                 list_add_tail(&e->list, &q->tx_list);
>
>                 WRITE_ONCE(desc->msg0, 0);
> @@ -1177,12 +1194,10 @@ static void airoha_qdma_tx_cleanup(struct airoha_qdma *qdma)
>                         struct airoha_qdma_desc *desc = &q->desc[j];
>                         struct sk_buff *skb = e->skb;
>
> -                       if (!e->dma_addr)
> +                       if (e->dma_type == AIROHA_DMA_UNMAPPED)
>                                 continue;
>
> -                       dma_unmap_single(qdma->eth->dev, e->dma_addr,
> -                                        e->dma_len, DMA_TO_DEVICE);
> -                       e->dma_addr = 0;
> +                       airoha_unmap_xmit_buf(qdma->eth, e);
>                         list_add_tail(&e->list, &q->tx_list);
>
>                         WRITE_ONCE(desc->ctrl, 0);
> @@ -2193,8 +2208,8 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
>         struct netdev_queue *txq;
>         struct airoha_queue *q;
>         LIST_HEAD(tx_list);
> +       dma_addr_t addr;
>         int i = 0, qid;
> -       void *data;
>         u16 index;
>         u8 fport;
>
> @@ -2250,24 +2265,22 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
>                 return NETDEV_TX_BUSY;
>         }
>
> -       len = skb_headlen(skb);
> -       data = skb->data;
> -
>         e = list_first_entry(&q->tx_list, struct airoha_queue_entry,
>                              list);
> +       len = skb_headlen(skb);
> +       addr = dma_map_single(netdev->dev.parent, skb->data, len,
> +                             DMA_TO_DEVICE);
> +       if (unlikely(dma_mapping_error(netdev->dev.parent, addr)))
> +               goto error_unlock;
> +
> +       e->dma_type = AIROHA_DMA_MAP_SINGLE;
>         index = e - q->entry;
>
>         while (true) {
>                 struct airoha_qdma_desc *desc = &q->desc[index];
>                 skb_frag_t *frag = &skb_shinfo(skb)->frags[i];
> -               dma_addr_t addr;
>                 u32 val;
>
> -               addr = dma_map_single(netdev->dev.parent, data, len,
> -                                     DMA_TO_DEVICE);
> -               if (unlikely(dma_mapping_error(netdev->dev.parent, addr)))
> -                       goto error_unmap;
> -
>                 list_move_tail(&e->list, &tx_list);
>                 e->skb = i == nr_frags - 1 ? skb : NULL;
>                 e->dma_addr = addr;
> @@ -2291,8 +2304,13 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
>                 if (++i == nr_frags)
>                         break;
>
> -               data = skb_frag_address(frag);
>                 len = skb_frag_size(frag);
> +               addr = skb_frag_dma_map(netdev->dev.parent, frag, 0, len,
> +                                       DMA_TO_DEVICE);
> +               if (unlikely(dma_mapping_error(netdev->dev.parent, addr)))
> +                       goto error_unmap;
> +
> +               e->dma_type = AIROHA_DMA_MAP_PAGE;
>         }
>         q->queued += i;
>
> @@ -2313,11 +2331,8 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
>         return NETDEV_TX_OK;
>
>  error_unmap:
> -       list_for_each_entry(e, &tx_list, list) {
> -               dma_unmap_single(netdev->dev.parent, e->dma_addr, e->dma_len,
> -                                DMA_TO_DEVICE);
> -               e->dma_addr = 0;
> -       }
> +       list_for_each_entry(e, &tx_list, list)
> +               airoha_unmap_xmit_buf(dev->eth, e);
>         list_splice(&tx_list, &q->tx_list);
>  error_unlock:
>         spin_unlock_bh(&q->lock);
> diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
> index d7ff8c5200e2..2765244d937c 100644
> --- a/drivers/net/ethernet/airoha/airoha_eth.h
> +++ b/drivers/net/ethernet/airoha/airoha_eth.h
> @@ -170,12 +170,19 @@ enum trtcm_param {
>  #define TRTCM_TOKEN_RATE_MASK                  GENMASK(23, 6)
>  #define TRTCM_TOKEN_RATE_FRACTION_MASK         GENMASK(5, 0)
>
> +enum airoha_dma_map_type {
> +       AIROHA_DMA_UNMAPPED,
> +       AIROHA_DMA_MAP_SINGLE,
> +       AIROHA_DMA_MAP_PAGE,
> +};
> +
>  struct airoha_queue_entry {
>         union {
>                 void *buf;
>                 struct {
>                         struct list_head list;
>                         struct sk_buff *skb;
> +                       enum airoha_dma_map_type dma_type;
>                 };
>         };
>         dma_addr_t dma_addr;
>
> ---
> base-commit: 232c4ca2343d1181cbfc061f9856d9591e397579
> change-id: 20260625-airoha-eth-skb_frag_dma_map-bcccd5d6e4b1
>
> Best regards,
> --
> Lorenzo Bianconi <lorenzo@kernel.org>
>
>

^ permalink raw reply

* Re: [PATCH net 0/7] xsk: fix AF_XDP multi-buffer Tx descriptor reclaim
From: Jason Xing @ 2026-06-26  0:24 UTC (permalink / raw)
  To: Stanislav Fomichev
  Cc: Maciej Fijalkowski, netdev, bpf, magnus.karlsson, stfomichev,
	kuba, pabeni, horms, bjorn
In-Reply-To: <aj1O4vKzCuodwgYL@devvm7509.cco0.facebook.com>

On Fri, Jun 26, 2026 at 12:05 AM Stanislav Fomichev
<sdf.kernel@gmail.com> wrote:
>
> On 06/25, Jason Xing wrote:
> > On Thu, Jun 25, 2026 at 12:37 AM Maciej Fijalkowski
> > <maciej.fijalkowski@intel.com> wrote:
> > >
> > > On Wed, Jun 24, 2026 at 08:38:20AM -0700, Stanislav Fomichev wrote:
> > > > On 06/23, Maciej Fijalkowski wrote:
> > > > > Hi,
> > > > >
> > > > > This series fixes several AF_XDP multi-buffer Tx paths where descriptors
> > > > > consumed from the Tx ring are not consistently returned to userspace
> > > > > through the completion ring when the packet is later dropped as invalid.
> > > > >
> > > > > The affected cases are invalid or oversized multi-buffer Tx packets in
> > > > > both the generic and zero-copy paths. In these cases, the kernel can
> > > > > consume one or more Tx descriptors while building or validating a
> > > > > multi-buffer packet, then drop the packet before it reaches the device.
> > > > > Userspace still owns the UMEM buffers only after the corresponding
> > > > > addresses are returned through the CQ. Missing completions therefore
> > > > > make userspace lose track of those buffers.
> > > > >
> > > > > The generic path fixes cover three related cases:
> > > > > * partially built multi-buffer skbs dropped by xsk_drop_skb();
> > > > >   continuation descriptors left in the Tx ring after xsk_build_skb()
> > > > >   reports overflow;
> > > > > * invalid descriptors encountered in the middle of a multi-buffer
> > > > >   packet, including the offending invalid descriptor itself.
> > > > >
> > > > > The zero-copy path is handled separately. The batched Tx parser now
> > > > > distinguishes descriptors that can be passed to the driver from
> > > > > descriptors that are consumed only because they belong to an invalid
> > > > > multi-buffer packet. Reclaim-only descriptors are written to the CQ
> > > > > address area and published in completion order, after any earlier
> > > > > driver-visible Tx descriptors.
> > > > >
> > > > > The ZC batching path can also retain drain state when userspace has not
> > > > > yet provided the end of an invalid multi-buffer packet. To keep this
> > > > > state local to the singular batched path, the series prevents a second
> > > > > Tx socket from joining the same pool while such drain state exists.
> > > > > During the singular-to-shared transition, Tx batching is gated,
> > > > > pre-existing readers are waited out, and bind fails with -EAGAIN if the
> > > > > existing socket still has pending drain state. This avoids adding
> > > > > multi-buffer drain handling to the shared-UMEM fallback path.
> > > > >
> > > > > The last two patches update xskxceiver so the tests account invalid
> > > > > multi-buffer Tx packets as descriptors that must be reclaimed, while
> > > > > still not expecting those invalid packets on the Rx side.
> > > > >
> > > > > This is a follow-up to Jason's changes [0] which were addressing generic
> > > > > xmit only and this set allows me to pass full xskxceiver test suite run
> > > > > against ice driver.
> > > >
> > > > There is a fair amount of feedback from sashiko already :-( So the meta
> > > > question from me is: is it time to scrap our current approach where
> > > > we parse descriptor by descriptor? (and maintain half-baked skb and
> > > > half-consumed descriptor queues)
> > > >
> > > > Should we:
> > > >
> > > > 1. do desc[MAX_SKB_FRAGS] and xskq_cons_peek_desc until we exhaust
> > > > PKT_CONT (if the last packet has PKT_CONT, return EOVERFLOW to userspace
> > > > and do a full stop here)
> > > > 2. now that we really know the number of valid descriptors -> reserve
> > > > the cq space (if not -> EAGAIN)
> > > > 3. pre-allocate everything here (if at any point we have ENOMEM -> cleanup
> > > > locally, don't ever create semi-initialized skb)
> > > > 4. construct the skb
> > > > 5. xmit
> > >
> > > Yeah generic xmit became utterly horrible, haven't gone through sashiko
> > > reviews yet, but bare in mind this set also aligns zc side to what was
> > > previously being addressed by Jason.
> > >
> > > I believe planned logistics were to get these fixes onto net and then
> > > Jason had an implementation of batching on generic xmit, directed towards
> > > -next and that's where we could address current flow.
> >
> > Agreed. That's what I'm hoping for. There would be much more
> > discussion on how to do batch xmit in an elegant way, I believe.
>
> This doesn't have to depend on the batch rewrite, we should be able to rewrite
> this non-zc in net, this is still technically fixes, not feature work..
>
> There was already a couple of revisions with this drain_cont approach
> and every time I look at it feels like the cure is worse than the
> decease :-( Obviously not gonna stop you from going with the current approach,
> but these fixes feel a bit of a wasted effort to me (since the bugs keep
> coming and we are piling more complexity).

I see your point, but rewriting is something that cannot be easily
applied to the stable branches? Until now, we fix issues one by one
which have an explicit target branch (because of the fixes tag). Cross
fingers :(

Sashiko has the magic to find out the hidden bugs more than ever and
AF_XDP is not the only place where a pile of reports are coming in.

My take is that batch xmit has been appending too long and at least so
far less and less bugs are found by sashiko. I believe if the mode is
changed to batch xmit, there are likely to be new and challenging
problems to discuss. I prefer to solve questions of the batch xmit
series.

BTW, would you both come to Netdev 0x1a next month? I believe we could
sit around the table and discuss some future plans there (in xdp
workshop?).
https://netdevconf.info/0x1A/sessions/workshop/xdp-workshop.html

Thanks,
Jason

^ permalink raw reply

* Re: [PATCH net] net: gianfar: use of_irq_get()
From: Rosen Penev @ 2026-06-26  0:42 UTC (permalink / raw)
  To: Simon Horman
  Cc: netdev, claudiu.manoil, andrew+netdev, davem, edumazet, kuba,
	pabeni, afleming, linux-kernel
In-Reply-To: <20260625093630.1173136-1-horms@kernel.org>

On Thu, Jun 25, 2026 at 2:36 AM Simon Horman <horms@kernel.org> wrote:
>
> This is an AI-generated review of your patch. The human sending this
> email has considered the AI review valid, or at least plausible.
> Full review at: https://netdev-ai.bots.linux.dev/sashiko/
> ---
> net: gianfar: use of_irq_get()
>
> This patch switches gfar_parse_group() from irq_of_parse_and_map() to
> of_irq_get() and widens the irq field in struct gfar_irqinfo from
> unsigned int to int. The stated goals are to fix a leak from a missing
> irq_dispose_mapping() and to enable -EPROBE_DEFER propagation.
>
> > diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
> > index 3271de5844f8..17a0d0787ed2 100644
> > --- a/drivers/net/ethernet/freescale/gianfar.c
> > +++ b/drivers/net/ethernet/freescale/gianfar.c
> > @@ -514,15 +514,15 @@ static int gfar_parse_group(struct device_node *np,
> >       if (!grp->regs)
> >               return -ENOMEM;
> >
> > -     gfar_irq(grp, TX)->irq = irq_of_parse_and_map(np, 0);
> > +     gfar_irq(grp, TX)->irq = of_irq_get(np, 0);
> >
> >       /* If we aren't the FEC we have multiple interrupts */
> >       if (model && strcasecmp(model, "FEC")) {
> > -             gfar_irq(grp, RX)->irq = irq_of_parse_and_map(np, 1);
> > -             gfar_irq(grp, ER)->irq = irq_of_parse_and_map(np, 2);
> > -             if (!gfar_irq(grp, TX)->irq ||
> > -                 !gfar_irq(grp, RX)->irq ||
> > -                 !gfar_irq(grp, ER)->irq)
> > +             gfar_irq(grp, RX)->irq = of_irq_get(np, 1);
> > +             gfar_irq(grp, ER)->irq = of_irq_get(np, 2);
> > +             if (gfar_irq(grp, TX)->irq < 0 ||
> > +                 gfar_irq(grp, RX)->irq < 0 ||
> > +                 gfar_irq(grp, ER)->irq < 0)
> >                       return -EINVAL;
> >       }
>
> [High]
> Does this change miss the 0-return mapping failure case?
>
> The kernel-doc on of_irq_get() in drivers/of/irq.c says it returns:
>
>     Linux IRQ number on success, or 0 on the IRQ mapping failure, or
>     -EPROBE_DEFER ..., or error code in case of any other failure.
>
> The old test rejected an irq value of 0 with !gfar_irq(grp, *)->irq,
> which caught both irq_of_parse_and_map()'s and of_irq_get()'s
> zero-on-failure. The new test only rejects values strictly less than
> zero, so a 0 returned from of_irq_get() is now stored as the IRQ and
> later flows into request_irq()/free_irq() during probe and unbind.
>
> Should the test be <= 0, or split so that negative errors are
> propagated and 0 still triggers a failure?
>
> [High]
> Is -EPROBE_DEFER lost here?
>
> The commit message states:
>
>     Changed irq to an int as required by the of_irq_get API as it
>     supports -EPROBE_DEFER.
>
> However, the only error path is:
>
>     if (gfar_irq(grp, TX)->irq < 0 ||
>         gfar_irq(grp, RX)->irq < 0 ||
>         gfar_irq(grp, ER)->irq < 0)
>             return -EINVAL;
>
> of_irq_get() returns -EPROBE_DEFER when irq_find_host() cannot yet
> locate the parent interrupt controller. Collapsing every negative
> return into -EINVAL prevents the driver core from retrying the probe
> once the interrupt controller appears.
>
> Should the actual error from of_irq_get() be propagated, for example:
>
>     int ret = gfar_irq(grp, TX)->irq;
>     if (ret < 0)
>             return ret;
>
> so that -EPROBE_DEFER reaches gfar_of_init() and then gfar_probe()?
>
> [Medium]
> Can the commit message description be revisited?
>
> The message states:
>
>     of_irq_get() differs from irq_of_parse_and_map() in that the latter
>     requires calling irq_dispose_mapping() when done, which is missing
>     in the driver. Meaning it leaks memory.
>
>     No need to map it anyway. Just need the value stored in the irq
>     field.
>
> Looking at of_irq_get() in drivers/of/irq.c:
>
>     int of_irq_get(struct device_node *dev, int index)
>     {
>             ...
>             rc = irq_create_of_mapping(&oirq);
>             ...
>     }
>
> of_irq_get() ends with the same irq_create_of_mapping() call that
> irq_of_parse_and_map() makes, so the resulting virq mapping is created
> identically by both APIs.
>
> If the previous code leaked, does the new code not leak in the same
> way? And does the Fixes: b31a1d8b4151 tag accurately describe this
> change, given that it may cause stable-tree selection on the basis of a
> leak that does not appear to exist?
Meh I'll submit to net-next. This is way too messy to fix for net.

^ permalink raw reply

* Re: [RFC net-next 00/17] MPTCP KTLS support
From: Cong Wang @ 2026-06-26  0:42 UTC (permalink / raw)
  To: Jakub Kicinski
  Cc: Geliang Tang, Matthieu Baerts, Mat Martineau, David S. Miller,
	Eric Dumazet, Paolo Abeni, Simon Horman, Neal Cardwell,
	Kuniyuki Iwashima, John Fastabend, Sabrina Dubroca,
	Hannes Reinecke, Geliang Tang, netdev, mptcp, Gang Yan, Zqiang
In-Reply-To: <20260622090059.5d1813dd@kernel.org>

On Mon, Jun 22, 2026 at 09:00:59AM -0700, Jakub Kicinski wrote:
> On Mon, 22 Jun 2026 18:43:20 +0800 Geliang Tang wrote:
> > Subject: [RFC net-next 00/17] MPTCP KTLS support
> 
> Please no. We have a ton of unfixed bugs and may have to revert some of
> the features we dropped back in. I'd prefer to avoid large new bug
> surfaces until we reach an LTS release.

Is this specifically for kTLS? Or the whole networking subsystem?

Asking because if it is the latter you probably want to announce this
new rule offically and update Documentation/process/maintainer-netdev.rst

Regards,
Cong

^ permalink raw reply

* iproute2: trailing whitespace in man pages
From: Bjarni Ingi Gislason @ 2026-06-26  1:54 UTC (permalink / raw)
  To: netdev; +Cc: Debian Bug Tracking System

[-- Attachment #1: Type: text/plain, Size: 47886 bytes --]

Package: iproute2 (in Debian)
Version: 7.1.0-1
Severity: minor

  Additional remarks.

  Mails from me to "submit@bugs.debian.org" are no longer acknowledged.  A
Debian maintainer told me, that he would contact the mail administrator
about me not wanting to send bugs upstream.

-.-

Dear Maintainer,

   * What led up to the situation?

     Checking for defects with a new version

test-[g|n]roff -mandoc -t -K utf8 -rF0 -rHY=0 -rCHECKSTYLE=0 -ww -z < "man page"

  [Use 

grep -n -e ' $' -e '\\~$' -e ' \\f.$' -e ' \\"' <file>

  to find (most) trailing spaces.]

  ["test-groff" is a script in the repository for "groff"; is not shipped]
(local copy and "troff" slightly changed by me).

  [The fate of "test-nroff" was decided in groff bug #55941.]

   * What was the outcome of this action?

troff:/tmp/gz.roff.tw9zTq:10: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:15: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:20: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:34: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:36: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:38: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:40: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:41: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:42: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:43: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:44: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:45: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:46: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:47: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:48: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:49: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:50: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:55: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:56: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tw9zTq:57: warning: trailing whitespace [-w trail]
/usr/share/man/man8/bridge.8.gz

troff:/tmp/gz.roff.m7ah0F:12: warning: trailing whitespace [-w trail]
/usr/share/man/man8/dcb-app.8.gz

troff:/tmp/gz.roff.lEZOzh:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.lEZOzh:32: warning: trailing whitespace [-w trail]
/usr/share/man/man8/dcb-apptrust.8.gz

troff:/tmp/gz.roff.WIScEl:12: warning: trailing whitespace [-w trail]
/usr/share/man/man8/dcb-buffer.8.gz

troff:/tmp/gz.roff.lQyzHW:11: warning: trailing whitespace [-w trail]
/usr/share/man/man8/dcb-dcbx.8.gz

troff:/tmp/gz.roff.i604Vp:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.i604Vp:43: warning: trailing whitespace [-w trail]
/usr/share/man/man8/dcb-ets.8.gz

troff:/tmp/gz.roff.21mI9Z:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.21mI9Z:37: warning: trailing whitespace [-w trail]
/usr/share/man/man8/dcb-maxrate.8.gz

troff:/tmp/gz.roff.tNIhrB:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.tNIhrB:38: warning: trailing whitespace [-w trail]
/usr/share/man/man8/dcb-pfc.8.gz

troff:/tmp/gz.roff.rSgJgv:12: warning: trailing whitespace [-w trail]
/usr/share/man/man8/dcb-rewr.8.gz

troff:/tmp/gz.roff.Q8vb3N:11: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Q8vb3N:18: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Q8vb3N:24: warning: trailing whitespace [-w trail]
/usr/share/man/man8/dcb.8.gz

troff:/tmp/gz.roff.IodjFN:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.IodjFN:17: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.IodjFN:32: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.IodjFN:34: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.IodjFN:36: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.IodjFN:54: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.IodjFN:123: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.IodjFN:133: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.IodjFN:149: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.IodjFN:175: warning: trailing whitespace [-w trail]
/usr/share/man/man8/devlink-dev.8.gz

troff:/tmp/gz.roff.Nx3P7S:13: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Nx3P7S:18: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Nx3P7S:28: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Nx3P7S:32: warning: trailing whitespace [-w trail]
/usr/share/man/man8/devlink-dpipe.8.gz

troff:/tmp/gz.roff.f7fvNK:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.f7fvNK:17: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.f7fvNK:24: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.f7fvNK:66: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.f7fvNK:68: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.f7fvNK:184: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.f7fvNK:188: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.f7fvNK:193: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.f7fvNK:197: warning: trailing whitespace [-w trail]
/usr/share/man/man8/devlink-health.8.gz

troff:/tmp/gz.roff.hTtjSy:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.hTtjSy:17: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.hTtjSy:24: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.hTtjSy:25: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.hTtjSy:29: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.hTtjSy:50: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.hTtjSy:54: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.hTtjSy:55: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.hTtjSy:56: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.hTtjSy:68: warning: trailing whitespace [-w trail]
/usr/share/man/man8/devlink-lc.8.gz

troff:/tmp/gz.roff.soeA6o:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:17: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:22: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:24: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:29: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:35: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:50: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:66: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:68: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:69: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:71: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:74: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:77: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:80: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:83: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:86: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:91: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:101: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:127: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.soeA6o:167: warning: treating total indentation -72u as zero [-w range]
/usr/share/man/man8/devlink-port.8.gz

troff:/tmp/gz.roff.kYqBeN:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.kYqBeN:17: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.kYqBeN:26: warning: trailing whitespace [-w trail]
/usr/share/man/man8/devlink-rate.8.gz

troff:/tmp/gz.roff.9tHyhr:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.9tHyhr:17: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.9tHyhr:28: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.9tHyhr:48: warning: trailing whitespace [-w trail]
/usr/share/man/man8/devlink-region.8.gz

troff:/tmp/gz.roff.9MYeZd:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.9MYeZd:17: warning: trailing whitespace [-w trail]
/usr/share/man/man8/devlink-resource.8.gz

troff:/tmp/gz.roff.ZhPBEk:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:17: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:22: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:23: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:28: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:29: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:31: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:39: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:41: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:43: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:48: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:49: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:51: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:59: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:61: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:63: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:66: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:67: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:69: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZhPBEk:71: warning: trailing whitespace [-w trail]
/usr/share/man/man8/devlink-sb.8.gz

troff:/tmp/gz.roff.cbJFkk:17: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.cbJFkk:79: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.cbJFkk:114: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.cbJFkk:139: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.cbJFkk:143: warning: trailing whitespace [-w trail]
/usr/share/man/man8/devlink-trap.8.gz

troff:/tmp/gz.roff.QOaboD:10: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.QOaboD:16: warning: trailing whitespace [-w trail]
/usr/share/man/man8/devlink.8.gz

troff:/tmp/gz.roff.m0E9ov:11: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.m0E9ov:19: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.m0E9ov:29: warning: trailing whitespace [-w trail]
/usr/share/man/man8/dpll.8.gz

troff:/tmp/gz.roff.hhba1k:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.hhba1k:19: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.hhba1k:24: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.hhba1k:29: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.hhba1k:31: warning: trailing whitespace [-w trail]
/usr/share/man/man8/genl.8.gz

troff:/tmp/gz.roff.UspeXf:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:17: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:27: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:29: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:31: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:33: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:39: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:41: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:43: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:45: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:47: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:49: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:51: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:63: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:65: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:67: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:69: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:71: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:76: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.UspeXf:77: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-address.8.gz

troff:/tmp/gz.roff.ACnG5f:10: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ACnG5f:15: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ACnG5f:17: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ACnG5f:56: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-addrlabel.8.gz

troff:/tmp/gz.roff.5eqgIA:14: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.5eqgIA:21: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.5eqgIA:27: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.5eqgIA:31: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.5eqgIA:35: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.5eqgIA:39: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.5eqgIA:48: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.5eqgIA:52: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.5eqgIA:56: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.5eqgIA:60: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-fou.8.gz

troff:/tmp/gz.roff.muormS:10: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.muormS:21: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.muormS:25: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.muormS:49: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-ioam.8.gz

troff:/tmp/gz.roff.YZqY4h:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.YZqY4h:18: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.YZqY4h:85: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.YZqY4h:232: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-l2tp.8.gz

troff:/tmp/gz.roff.x9nPAk:10: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:59: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:67: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:159: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:164: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:186: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:195: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:197: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:223: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:224: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:226: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:227: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:228: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:229: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:230: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:236: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:237: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:248: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:249: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.x9nPAk:256: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-link.8.gz

troff:/tmp/gz.roff.r9LukD:5: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.r9LukD:64: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.r9LukD:65: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.r9LukD:67: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.r9LukD:75: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.r9LukD:77: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.r9LukD:80: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.r9LukD:83: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.r9LukD:85: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-macsec.8.gz

troff:/tmp/gz.roff.fk7Uej:12: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-maddress.8.gz

troff:/tmp/gz.roff.OtuwHM:11: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.OtuwHM:17: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.OtuwHM:45: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.OtuwHM:51: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.OtuwHM:57: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.OtuwHM:58: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-monitor.8.gz

troff:/tmp/gz.roff.DLgQwy:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DLgQwy:14: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DLgQwy:16: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DLgQwy:22: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DLgQwy:30: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DLgQwy:32: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DLgQwy:35: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DLgQwy:37: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DLgQwy:39: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DLgQwy:42: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DLgQwy:45: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DLgQwy:52: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DLgQwy:88: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DLgQwy:89: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DLgQwy:92: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-mptcp.8.gz

troff:/tmp/gz.roff.Bf2muc:9: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Bf2muc:10: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Bf2muc:11: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Bf2muc:13: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Bf2muc:15: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Bf2muc:17: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-mroute.8.gz

troff:/tmp/gz.roff.aIjjMP:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.aIjjMP:17: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.aIjjMP:18: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.aIjjMP:20: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.aIjjMP:24: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.aIjjMP:26: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.aIjjMP:27: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.aIjjMP:28: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.aIjjMP:29: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.aIjjMP:30: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.aIjjMP:35: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.aIjjMP:37: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.aIjjMP:39: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-neighbour.8.gz

troff:/tmp/gz.roff.sjvvc4:9: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-netconf.8.gz

troff:/tmp/gz.roff.bAu8qy:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.bAu8qy:46: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-netns.8.gz

troff:/tmp/gz.roff.nM3cIw:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:18: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:19: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:23: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:28: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:40: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:42: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:44: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:46: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:48: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:49: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:53: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:59: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:60: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:62: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:64: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:65: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:67: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:68: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.nM3cIw:70: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-nexthop.8.gz

troff:/tmp/gz.roff.Kn3w81:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Kn3w81:18: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Kn3w81:57: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Kn3w81:59: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-ntable.8.gz

troff:/tmp/gz.roff.gv3LBB:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:18: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:19: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:33: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:36: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:38: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:40: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:42: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:44: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:46: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:56: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:60: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:62: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:64: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:66: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:68: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:70: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:72: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:74: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gv3LBB:84: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-route.8.gz

troff:/tmp/gz.roff.6owsuu:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:31: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:34: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:36: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:38: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:40: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:42: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:44: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:46: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:48: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:49: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:51: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:53: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:54: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:55: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:56: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:57: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:58: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:59: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.6owsuu:61: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-rule.8.gz

troff:/tmp/gz.roff.6yXkbF:10: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-sr.8.gz

troff:/tmp/gz.roff.glO7gb:11: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.glO7gb:18: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.glO7gb:20: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.glO7gb:28: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-stats.8.gz

troff:/tmp/gz.roff.XiAasB:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.XiAasB:25: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.XiAasB:26: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-tcp_metrics.8.gz

troff:/tmp/gz.roff.XtavYp:10: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-token.8.gz

troff:/tmp/gz.roff.TS3gWw:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.TS3gWw:18: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.TS3gWw:20: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.TS3gWw:25: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.TS3gWw:34: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.TS3gWw:39: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.TS3gWw:41: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.TS3gWw:59: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.TS3gWw:76: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.TS3gWw:81: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-tunnel.8.gz

troff:/tmp/gz.roff.5llFkR:11: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.5llFkR:28: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-vrf.8.gz

troff:/tmp/gz.roff.91zMPC:13: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:19: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:29: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:103: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:158: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:171: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:175: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:183: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:198: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:240: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:274: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:325: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:327: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:345: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:363: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:367: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:371: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:427: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:448: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.91zMPC:564: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip-xfrm.8.gz

troff:/tmp/gz.roff.gY3yJ3:10: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gY3yJ3:16: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gY3yJ3:21: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gY3yJ3:31: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gY3yJ3:39: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gY3yJ3:169: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gY3yJ3:175: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ip.8.gz

troff:/tmp/gz.roff.j0dcO5:10: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.j0dcO5:15: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.j0dcO5:111: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.j0dcO5:112: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.j0dcO5:203: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.j0dcO5:204: warning: trailing whitespace [-w trail]
/usr/share/man/man8/netshaper.8.gz

troff:/tmp/gz.roff.EOKA9l:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.EOKA9l:17: warning: trailing whitespace [-w trail]
/usr/share/man/man8/rdma-dev.8.gz

troff:/tmp/gz.roff.j9CeKZ:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.j9CeKZ:17: warning: trailing whitespace [-w trail]
/usr/share/man/man8/rdma-link.8.gz

troff:/tmp/gz.roff.NBliDx:16: warning: trailing whitespace [-w trail]
/usr/share/man/man8/rdma-monitor.8.gz

troff:/tmp/gz.roff.n7n6Ij:10: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.n7n6Ij:15: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.n7n6Ij:16: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.n7n6Ij:21: warning: trailing whitespace [-w trail]
/usr/share/man/man8/rdma-resource.8.gz

troff:/tmp/gz.roff.zNQGc9:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.zNQGc9:40: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.zNQGc9:85: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.zNQGc9:89: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.zNQGc9:93: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.zNQGc9:97: warning: trailing whitespace [-w trail]
/usr/share/man/man8/rdma-statistic.8.gz

troff:/tmp/gz.roff.w2n0Tg:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.w2n0Tg:17: warning: trailing whitespace [-w trail]
/usr/share/man/man8/rdma-system.8.gz

troff:/tmp/gz.roff.G452XU:10: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.G452XU:16: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.G452XU:21: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.G452XU:26: warning: trailing whitespace [-w trail]
/usr/share/man/man8/rdma.8.gz

troff:/tmp/gz.roff.8E9eVD:10: warning: trailing whitespace [-w trail]
/usr/share/man/man8/rtmon.8.gz

troff:/tmp/gz.roff.cESP7P:447: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.cESP7P:607: warning: trailing whitespace [-w trail]
/usr/share/man/man8/ss.8.gz

troff:/tmp/gz.roff.ux4fN1:9: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ux4fN1:11: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-basic.8.gz

troff:/tmp/gz.roff.E5yQLK:9: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-cgroup.8.gz

troff:/tmp/gz.roff.xDoFMo:10: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.xDoFMo:49: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-connmark.8.gz

troff:/tmp/gz.roff.EPr6TY:15: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.EPr6TY:26: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-csum.8.gz

troff:/tmp/gz.roff.ozliFK:7: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ozliFK:9: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ozliFK:11: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ozliFK:13: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ozliFK:18: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-ct.8.gz

troff:/tmp/gz.roff.NlhG4f:34: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.NlhG4f:39: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.NlhG4f:51: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-dualpi2.8.gz

troff:/tmp/gz.roff.AXC30K:14: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.AXC30K:20: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.AXC30K:22: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.AXC30K:33: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.AXC30K:73: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-ematch.8.gz

troff:/tmp/gz.roff.Xqn4yW:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Xqn4yW:13: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Xqn4yW:21: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Xqn4yW:22: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Xqn4yW:24: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Xqn4yW:32: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Xqn4yW:34: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Xqn4yW:36: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Xqn4yW:38: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Xqn4yW:46: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Xqn4yW:47: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Xqn4yW:54: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Xqn4yW:55: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Xqn4yW:56: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.Xqn4yW:57: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-flow.8.gz

troff:/tmp/gz.roff.SN8HX6:8: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:9: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:11: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:13: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:22: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:24: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:26: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:28: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:29: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:30: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:32: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:34: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:35: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:36: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:38: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:40: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:41: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:42: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:44: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.SN8HX6:45: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-flower.8.gz

troff:/tmp/gz.roff.75BF9d:69: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-fq_codel.8.gz

troff:/tmp/gz.roff.ATqeiC:9: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-fw.8.gz

troff:/tmp/gz.roff.0gJmYD:11: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0gJmYD:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0gJmYD:21: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0gJmYD:24: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-gact.8.gz

troff:/tmp/gz.roff.1ht4Bu:9: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.1ht4Bu:11: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.1ht4Bu:13: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.1ht4Bu:15: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.1ht4Bu:16: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.1ht4Bu:17: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.1ht4Bu:19: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.1ht4Bu:22: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.1ht4Bu:26: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.1ht4Bu:32: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.1ht4Bu:36: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.1ht4Bu:59: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.1ht4Bu:67: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-ife.8.gz

troff:/tmp/gz.roff.eEZB5X:8: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.eEZB5X:10: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.eEZB5X:12: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-matchall.8.gz

troff:/tmp/gz.roff.BCTuKt:11: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.BCTuKt:15: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.BCTuKt:22: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.BCTuKt:26: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.BCTuKt:30: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-mirred.8.gz

troff:/tmp/gz.roff.KuFNwq:8: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.KuFNwq:9: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.KuFNwq:10: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.KuFNwq:14: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.KuFNwq:19: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.KuFNwq:23: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.KuFNwq:25: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.KuFNwq:27: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.KuFNwq:31: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.KuFNwq:35: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.KuFNwq:37: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.KuFNwq:40: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.KuFNwq:57: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.KuFNwq:80: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.KuFNwq:81: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-mpls.8.gz

troff:/tmp/gz.roff.9RiFlD:235: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.9RiFlD:237: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.9RiFlD:254: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.9RiFlD:274: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.9RiFlD:282: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.9RiFlD:284: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-mqprio.8.gz

troff:/tmp/gz.roff.t0JWAM:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.t0JWAM:22: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.t0JWAM:23: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-nat.8.gz

troff:/tmp/gz.roff.ZHcyYL:6: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:14: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:18: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:25: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:26: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:34: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:35: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:37: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:41: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:45: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:47: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:51: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:55: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:56: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:59: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:60: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:63: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:67: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:383: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZHcyYL:387: warning [page 1, line 269]: cannot adjust line in b adjust mode; overset by 4n [-w break]
/usr/share/man/man8/tc-netem.8.gz

troff:/tmp/gz.roff.DJ46bB:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DJ46bB:18: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DJ46bB:22: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DJ46bB:29: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DJ46bB:44: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DJ46bB:48: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DJ46bB:53: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DJ46bB:57: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DJ46bB:62: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DJ46bB:63: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DJ46bB:67: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DJ46bB:71: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DJ46bB:77: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DJ46bB:79: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.DJ46bB:80: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-pedit.8.gz

troff:/tmp/gz.roff.HpJEdr:34: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-police.8.gz

troff:/tmp/gz.roff.JYFwIE:9: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.JYFwIE:11: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.JYFwIE:13: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.JYFwIE:15: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-route.8.gz

troff:/tmp/gz.roff.TQDw2w:14: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.TQDw2w:16: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.TQDw2w:19: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-sample.8.gz

troff:/tmp/gz.roff.LzdwcT:69: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-skbedit.8.gz

troff:/tmp/gz.roff.EeoYee:8: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.EeoYee:9: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.EeoYee:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.EeoYee:13: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.EeoYee:17: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.EeoYee:19: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.EeoYee:21: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.EeoYee:23: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.EeoYee:26: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-skbmod.8.gz

troff:/tmp/gz.roff.LaXqMO:8: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.LaXqMO:12: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-tunnel_key.8.gz

troff:/tmp/gz.roff.0SnZpw:9: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:11: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:13: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:15: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:17: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:19: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:21: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:23: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:25: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:27: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:29: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:31: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:32: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:33: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:37: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:44: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:46: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:51: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:52: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.0SnZpw:53: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-u32.8.gz

troff:/tmp/gz.roff.ZLTTLY:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZLTTLY:16: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZLTTLY:20: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZLTTLY:24: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZLTTLY:28: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZLTTLY:30: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.ZLTTLY:33: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc-vlan.8.gz

troff:/tmp/gz.roff.bkv7BO:128: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.bkv7BO:129: warning: ignoring escape character before ']' [-w escape]
troff:/tmp/gz.roff.bkv7BO:717: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.bkv7BO:723: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tc.8.gz

troff:/tmp/gz.roff.My0dwn:57: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tipc-bearer.8.gz

troff:/tmp/gz.roff.bYd25b:18: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.bYd25b:27: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.bYd25b:28: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.bYd25b:30: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.bYd25b:32: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.bYd25b:42: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.bYd25b:53: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.bYd25b:62: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.bYd25b:66: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tipc-link.8.gz

troff:/tmp/gz.roff.rs4kL6:17: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tipc-media.8.gz

troff:/tmp/gz.roff.z8m3fR:15: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.z8m3fR:19: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.z8m3fR:23: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tipc-node.8.gz

an.tmac:/tmp/gz.roff.9VgwLV:30: warning: cannot call .SS while an input trap is pending
an.tmac:/tmp/gz.roff.9VgwLV:34: warning: cannot call .SS while an input trap is pending
/usr/share/man/man8/tipc-socket.8.gz

troff:/tmp/gz.roff.rBSHKg:14: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.rBSHKg:19: warning: trailing whitespace [-w trail]
/usr/share/man/man8/tipc.8.gz

troff:/tmp/gz.roff.gPfIxK:11: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gPfIxK:12: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.gPfIxK:17: warning: trailing whitespace [-w trail]
/usr/share/man/man8/vdpa-dev.8.gz

troff:/tmp/gz.roff.wHzGiy:11: warning: trailing whitespace [-w trail]
troff:/tmp/gz.roff.wHzGiy:16: warning: trailing whitespace [-w trail]
/usr/share/man/man8/vdpa-mgmtdev.8.gz

troff:/tmp/gz.roff.qSwXBM:10: warning: trailing whitespace [-w trail]
/usr/share/man/man8/vdpa.8.gz

   * What outcome did you expect instead?

     No output (no warnings).

-.-

  General remarks and further material, if a diff-file exist, are in the
attachments.


-- System Information:
Debian Release: forky/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 7.0.12+deb14.1-amd64 (SMP w/2 CPU threads; PREEMPT)
Locale: LANG=is_IS.iso88591, LC_CTYPE=is_IS.iso88591 (charmap=ISO-8859-1), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages iproute2 depends on:
ii  debconf [debconf-2.0]  1.5.92
ii  libbpf1                1:1.7.0-1
ii  libc6                  2.42-17
ii  libcap2                1:2.78-1
ii  libcap2-bin            1:2.78-1
ii  libdb5.3t64            5.3.28+dfsg2-11+b1
ii  libelf1t64             0.195-1
ii  libmnl0                1.0.5-3+b2
ii  libselinux1            3.10-1
ii  libtirpc3t64           1.3.7+ds-1
ii  libxtables12           1.8.13-1

iproute2 recommends no packages.

Versions of packages iproute2 suggests:
ii  python3  3.13.9-3+b1

-- debconf information excluded

[-- Attachment #2: general.bugs --]
[-- Type: text/plain, Size: 2248 bytes --]

  Check the output from "lintian" in the Debian distribution.

  Any program (person), that produces man pages, should check the output
for defects by using (both groff and nroff)

[gn]roff -mandoc -t -ww -b -z -K utf8 <man page>

  To find most trailing spaces use

grep -n -e ' $' -e ' \\f.$' -e ' \\"' <man page>

  The same goes for man pages that are used as an input.

-.-

  For a style guide use

  mandoc -T lint

-.-

  For general input conventions consult the man page "nroff(7)" (item
"Input conventions") or the Texinfo manual about the same item.

-.-

  Any "autogenerator" should check its products with the above mentioned
'groff', 'mandoc', and additionally with 'nroff ...'.

  It should also check its input files for too long (> 80) lines.

  This is just a simple quality control measure.

  The "autogenerator" may have to be corrected to get a better man page,
the source file may, and any additional file may.

-.-

  Common defects:

  Not removing trailing spaces (in in- and output).
  The reason for these trailing spaces should be found and eliminated.

  "git" has a "tool" to point out whitespace,
see for example "git-apply(1)" and git-config(1)")

-.-

  Not beginning each input sentence on a new line.

Line length and patch size should thus be reduced when that has been fixed.

  The script "reportbug" uses 'quoted-printable' encoding when a line is
longer than 1024 characters in an 'ascii' file.

  See man-pages(7), item "semantic newline".

-.-

The difference between the formatted output of the original
and patched file can be seen with:

  nroff -mandoc <file1> > <out1>
  nroff -mandoc <file2> > <out2>
  diff -d -u <out1> <out2>

and for groff, using

\"printf '%s\n%s\n' '.kern 0' '.ss 12 0' | groff -mandoc -Z - \"

instead of 'nroff -mandoc'

  Add the option '-t', if the file contains a table.

  Read the output from 'diff -d -u ...' with 'less -R' or similar.

-.-.

  If 'man' (man-db) is used to check the manual for warnings,
the following must be set:

  The option "-warnings=w"

  The environmental variable:

export MAN_KEEP_STDERR=yes (or any non-empty value)

  or

  (produce only warnings):

export MANROFFOPT="-ww -b -z"

export MAN_KEEP_STDERR=yes (or any non-empty value)

-.-

[-- Attachment #3: trailing.whitespace --]
[-- Type: message/rfc822, Size: 461 bytes --]

Subject: clean files of trailing whitespace

  Trailing whitespace is so unnecessary, that its presence may be removed
before files containing it are distributed.

  Some programs have a tool to point out its presence, like

gcc

  with option "-Wtrailing-whitespace"

git
  with option "apply --whitespace=..."

  and in ".git/config"

[core]
	whitespace=...

grep

  with option -e '[[:blank:]]$'

less

  with command "/ $"

mandoc -T lint

  default action

^ permalink raw reply

* Re: [PATCH 0/18] pull request (net-next): ipsec-next 2026-06-12
From: Yan Yan @ 2026-06-26  1:58 UTC (permalink / raw)
  To: Antony Antony
  Cc: Jakub Kicinski, Steffen Klassert, Nathan Harold, Antony Antony,
	David Miller, Herbert Xu, netdev, Tobias Brunner, Sabrina Dubroca
In-Reply-To: <CADHa2dAtGVsph3Kq0id7QqgNdJww0Q=Z1PK+=fomVxKE-Mmvjg@mail.gmail.com>

Hi Antony,

I ran the following test cases and two—4.2 and 6—are worth disucssing:

1.  Mark Inheritance: Creates one SA and migrates it without
specifying a new mark. [PASSED]
2.  Mark Update: Creates one SA with a specific mark and migrates it
to a new specific mark. [PASSED]
3.  State Update Isolation: Creates two SAs differing only by mark and
verifies that migrating one does not affect the other. [PASSED]
4.  Mark Collision:
    4.1 [Specific Mark] Creates two SAs differing only by mark: SA
(mark_1) and an SA (mark_2). Verifies migrating SA (mark_1) to mark_2
fails with EEXIST and both SAs intact. [PASSED]
    4.2 [Wildcard Mark] Creates two SAs differing only by mark: SA
(mark_1) and an SA (mark_none). Migrate the mark_none to mark_1.
Expecting failure with EEXIST and both SAs intact. [FAILED: SA
(mark_none) ends up being deleted]
5.  Mark Mismatch:
    5.1 Creates only a wildcard SA and verifying migration using a
specific mark fails with ESRCH; SA intact [PASSED]
    5.2 Creates only one SA (mark_1) and verifying migration using a
mark_2 fails with ESRCH; SA intact [PASSED]
6.  Mark Shadowing Failure:: Creates two SAs differing only by mark:
the first SA (mark_1) and the second SA (mark None). Migrating the SA
(mark_1) fails with ESRCH, two SAs remain untouched [PASSED]

--------------------------------
My questions are as follows:

Regarding 4.2 I believe is a kernel bug. During the pre-migration
collision check, the lookup for the mark_1 matches the wildcard SA
itself first, causing the kernel to miss the collision with the
existing specific SA with mark_1

At https://github.com/antonyantony/linux/blob/migrate-state-fixes-v0/net/xfrm/xfrm_user.c#L3450

x_new = xfrm_state_lookup(net, new_mark_key, &m.new_daddr, ----> BUG:
We are looking for the existence of SA (mark_1) but SA (mark_none) is
returned.
um->id.spi, um->id.proto, m.new_family);
if (x_new) {
    xfrm_state_put(x_new);
    if (x_new != x) { ----> BUG: We end up having x_new == x
    NL_SET_ERR_MSG(extack, "New SA tuple already occupied");
    err = -EEXIST;
    goto out;
}
/* self-match via wide mark mask; not a collision */

Would it be possible to traverse the entire list or create a lookup
method for an exact match?

Regarding  6.  I wrote the tests as per the kernel implementation but
I'm not sure it is intended. Intuitively, this migration should
succeed by finding and updating the specific SA (mark_1) instead of
failing. Is this failure considered an acceptable limit, or should we
aim to support exact-match lookup here?



On Wed, Jun 24, 2026 at 6:45 PM Yan Yan <evitayan@google.com> wrote:
>
> Hi Antony,
>
> Sure, I'm happy to write and run some tests. I should be able to have the results by the end of the week.
>
>
>
> --
> --
> Best,
> Yan



--
--
Best,
Yan

^ permalink raw reply

* [PATCH 0/2] vdpa_sim: fix suspend/reset and dma_unmap locking
From: Xiong Weimin @ 2026-06-26  2:05 UTC (permalink / raw)
  To: Jason Wang, Michael S . Tsirkin
  Cc: netdev, virtualization, linux-kernel, Xiong Weimin

From: Xiong Weimin <xiongweimin@kylinos.cn>

This series fixes two independent issues in the vDPA simulator:

1. Clear pending_kick on device reset so a deferred kick from a
   suspended device cannot be replayed after reset/re-init.

2. Hold iommu_lock across the full dma_unmap() path, including the
   passthrough-to-custom mapping transition, matching dma_map().

Both patches tested on an openEuler VM running kernel 6.16.8: built
vdpa_sim.ko from /usr/src/linux-6.16.8 and reloaded vdpa_sim /
vdpa_sim_net successfully.

Xiong Weimin (2):
  vdpa_sim: clear pending_kick on device reset
  vdpa_sim: hold iommu_lock across dma_unmap passthrough transition

---
 drivers/vdpa/vdpa_sim/vdpa_sim.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

-- 
2.43.0


^ permalink raw reply

* [PATCH 2/2] vdpa_sim: hold iommu_lock across dma_unmap passthrough transition
From: Xiong Weimin @ 2026-06-26  2:05 UTC (permalink / raw)
  To: Jason Wang, Michael S . Tsirkin
  Cc: netdev, virtualization, linux-kernel, Xiong Weimin
In-Reply-To: <20260626020545.607600-1-15927021679@163.com>

From: Xiong Weimin <xiongweimin@kylinos.cn>

vdpasim_dma_map() updates the IOTLB and the passthrough (iommu_pt)
state under iommu_lock.  vdpasim_dma_unmap() clears iommu_pt and
resets the IOTLB before taking iommu_lock, then deletes the mapping
while holding the lock.

A concurrent dma_map(), dma_unmap(), or reset path that also touches
the same address space can therefore observe or modify the IOTLB and
iommu_pt state without consistent locking.

Perform the passthrough transition and range deletion under the same
iommu_lock scope, matching dma_map().

Tested-on: openEuler VM (6.16.8, /usr/src/linux-6.16.8)
Tested-by: Xiong Weimin <xiongweimin@kylinos.cn>

Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
 drivers/vdpa/vdpa_sim/vdpa_sim.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -736,12 +736,11 @@ static int vdpasim_dma_unmap(struct vdpa_device *vdpa, unsigned int asid,
 	if (asid >= vdpasim->dev_attr.nas)
 		return -EINVAL;
 
+	spin_lock(&vdpasim->iommu_lock);
 	if (vdpasim->iommu_pt[asid]) {
 		vhost_iotlb_reset(&vdpasim->iommu[asid]);
 		vdpasim->iommu_pt[asid] = false;
 	}
-
-	spin_lock(&vdpasim->iommu_lock);
 	vhost_iotlb_del_range(&vdpasim->iommu[asid], iova, iova + size - 1);
 	spin_unlock(&vdpasim->iommu_lock);
 
-- 
2.43.0


^ permalink raw reply

* [PATCH 1/2] vdpa_sim: clear pending_kick on device reset
From: Xiong Weimin @ 2026-06-26  2:05 UTC (permalink / raw)
  To: Jason Wang, Michael S . Tsirkin
  Cc: netdev, virtualization, linux-kernel, Xiong Weimin
In-Reply-To: <20260626020545.607600-1-15927021679@163.com>

From: Xiong Weimin <xiongweimin@kylinos.cn>

vdpasim_kick_vq() sets pending_kick when a virtqueue is kicked while
the device is suspended (!running but DRIVER_OK).  vdpasim_resume()
later replays kicks for all virtqueues when pending_kick is set.

vdpasim_do_reset() clears running and status but leaves pending_kick
unchanged.  If a kick is deferred during suspend and the device is
reset before resume, a later resume can spuriously kick every
virtqueue even though no new work was queued after reset.

Clear pending_kick in vdpasim_do_reset() together with the other
device state that must not survive a reset.

Tested-on: openEuler VM (6.16.8, /usr/src/linux-6.16.8)
Tested-by: Xiong Weimin <xiongweimin@kylinos.cn>

Signed-off-by: Xiong Weimin <xiongweimin@kylinos.cn>
---
 drivers/vdpa/vdpa_sim/vdpa_sim.c | 1 +
 1 file changed, 1 insertion(+)

--- a/drivers/vdpa/vdpa_sim/vdpa_sim.c
+++ b/drivers/vdpa/vdpa_sim/vdpa_sim.c
@@ -161,6 +161,7 @@ static void vdpasim_do_reset(struct vdpasim *vdpasim, u32 flags)
 	}
 
 	vdpasim->running = false;
+	vdpasim->pending_kick = false;
 	spin_unlock(&vdpasim->iommu_lock);
 
 	vdpasim->features = 0;
-- 
2.43.0


^ permalink raw reply

* 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

* [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: [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

* 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

* [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 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


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox