* 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
* Re: [PATCH v6 10/10] rust: module: update MAINTAINERS to cover module.rs
From: Alvin Sun @ 2026-06-26 3:01 UTC (permalink / raw)
To: Gary Guo, Miguel Ojeda, Boqun Feng, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
Danilo Krummrich, Luis Chamberlain, Petr Pavlu, Daniel Gomez,
Sami Tolvanen, Aaron Tomlin, Greg Kroah-Hartman,
Rafael J. Wysocki, David Airlie, Simona Vetter, Daniel Almeida,
Arnd Bergmann, Brendan Higgins, David Gow, Rae Moar, Breno Leitao,
Jens Axboe, Dave Ertman, Leon Romanovsky, Igor Korotin,
FUJITA Tomonori, Bjorn Helgaas, Krzysztof Wilczyński,
Arve Hjønnevåg, Todd Kjos, Christian Brauner,
Carlos Llamas
Cc: rust-for-linux, linux-modules, driver-core, dri-devel, nova-gpu,
linux-kselftest, kunit-dev, linux-block, linux-kernel, netdev,
linux-pci
In-Reply-To: <DJI7HR91X68U.3BVK3U4OJC18B@garyguo.net>
On 6/25/26 22:39, Gary Guo wrote:
> On Wed Jun 24, 2026 at 4:00 PM BST, Alvin Sun wrote:
>> Module types now live in `rust/kernel/module.rs` alongside
>> `rust/kernel/module_param.rs`. Update the MODULE SUPPORT file pattern
>> from `rust/kernel/module_param.rs` to `rust/kernel/module*.rs` so both
>> files are covered.
>>
>> Assisted-by: opencode:glm-5.2
> Did you actually use a LLM for this patch even? :)
Yes, I've created a skill that generates commit messages for the code I
modify
manually.
>
>> Link: https://lore.kernel.org/rust-for-linux/8ea21b29-9baf-4926-a16f-7d21c5a1a1b8@suse.com
>> Signed-off-by: Alvin Sun <alvin.sun@linux.dev>
> This patch should probably be squashed into the actual move, i.e. patch 1.
Sure. Looking at the change history of the `MAINTAINERS` file, the
modifications
are always in standalone commits, so I followed the same convention.
Best regards,
Alvin
>
> Best,
> Gary
>
>> ---
>> MAINTAINERS | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index e035a3be797c4..74733de3e41ee 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -17984,7 +17984,7 @@ F: include/linux/module*.h
>> F: kernel/module/
>> F: lib/test_kmod.c
>> F: lib/tests/module/
>> -F: rust/kernel/module_param.rs
>> +F: rust/kernel/module*.rs
>> F: rust/macros/module.rs
>> F: scripts/module*
>> F: tools/testing/selftests/kmod/
>
^ permalink raw reply
* Re: [PATCH v29 4/5] sfc: obtain and map cxl range using devm_cxl_probe_mem
From: Richard Cheng @ 2026-06-26 3:52 UTC (permalink / raw)
To: alejandro.lucero-palau
Cc: linux-cxl, netdev, dan.j.williams, edward.cree, davem, kuba,
pabeni, edumazet, dave.jiang, Alejandro Lucero, Edward Cree
In-Reply-To: <20260622124010.2192888-5-alejandro.lucero-palau@amd.com>
On Mon, Jun 22, 2026 at 01:40:09PM +0800, alejandro.lucero-palau@amd.com wrote:
> From: Alejandro Lucero <alucerop@amd.com>
>
> Use core API for safely obtain the CXL range linked to an HDM committed
> by the BIOS. Map such a range for being used as the ctpio buffer.
>
> A potential user space action through sysfs unbinding or core cxl
> modules remove will trigger sfc driver device detachment, with that case
> not racing with this mapping as this is done during driver probe and
> therefore protected with device lock against those user space actions.
>
> Signed-off-by: Alejandro Lucero <alucerop@amd.com>
> Reviewed-by: Dave Jiang <dave.jiang@intel.com>
> Acked-by: Edward Cree <ecree.xilinx@gmail.com>
> ---
> drivers/net/ethernet/sfc/efx.c | 2 ++
> drivers/net/ethernet/sfc/efx_cxl.c | 23 +++++++++++++++++++++++
> drivers/net/ethernet/sfc/efx_cxl.h | 3 +++
> 3 files changed, 28 insertions(+)
>
> diff --git a/drivers/net/ethernet/sfc/efx.c b/drivers/net/ethernet/sfc/efx.c
> index 61cbb6cfc360..3806cd3dd7f4 100644
> --- a/drivers/net/ethernet/sfc/efx.c
> +++ b/drivers/net/ethernet/sfc/efx.c
> @@ -984,6 +984,7 @@ static void efx_pci_remove(struct pci_dev *pci_dev)
> efx_fini_io(efx);
>
> probe_data = container_of(efx, struct efx_probe_data, efx);
> + efx_cxl_exit(probe_data);
>
> pci_dbg(efx->pci_dev, "shutdown successful\n");
>
> @@ -1242,6 +1243,7 @@ static int efx_pci_probe(struct pci_dev *pci_dev,
> return 0;
>
> fail3:
> + efx_cxl_exit(probe_data);
> efx_fini_io(efx);
> fail2:
> efx_fini_struct(efx);
> diff --git a/drivers/net/ethernet/sfc/efx_cxl.c b/drivers/net/ethernet/sfc/efx_cxl.c
> index 18b535b3ea40..3e7c950f83e9 100644
> --- a/drivers/net/ethernet/sfc/efx_cxl.c
> +++ b/drivers/net/ethernet/sfc/efx_cxl.c
> @@ -18,6 +18,7 @@ int efx_cxl_init(struct efx_probe_data *probe_data)
> {
> struct efx_nic *efx = &probe_data->efx;
> struct pci_dev *pci_dev = efx->pci_dev;
> + struct range cxl_pio_range;
> struct efx_cxl *cxl;
> u16 dvsec;
> int rc;
> @@ -73,9 +74,31 @@ int efx_cxl_init(struct efx_probe_data *probe_data)
> return -ENODEV;
> }
>
> + cxl->cxlmd = devm_cxl_probe_mem(&cxl->cxlds, &cxl_pio_range);
> + if (IS_ERR(cxl->cxlmd)) {
> + pci_err(pci_dev, "CXL accel memdev creation failed\n");
> + return PTR_ERR(cxl->cxlmd);
> + }
> +
> + cxl->ctpio_cxl = ioremap_wc(cxl_pio_range.start,
> + range_len(&cxl_pio_range));
Hi Alejandro,
A small question here,
Is it possible that the FW would commit a region bigger than the range ?
The committed CXL region length is never validated against the PIO window size.
The legacy patch sizes wc_mem_map_size to cover the VI-strided PIO offset, but
here we ioremap whatever the BIOS comitted and assume it's EFX_CTPIO_BUFFER_SIZE.
Maybe adding
"""
if (range_len(&cxl_pio_range) < EFX_CTPIO_BUFFER_SIZE)
return -EINVAL;
"""
Would be worthy ?
Let me know what you think.
Best regards,
Richard Cheng
> + if (!cxl->ctpio_cxl) {
> + pci_err(pci_dev, "CXL ioremap region (%pra) failed\n",
> + &cxl_pio_range);
> + return -ENOMEM;
> + }
> +
> probe_data->cxl = cxl;
>
> return 0;
> }
>
> +void efx_cxl_exit(struct efx_probe_data *probe_data)
> +{
> + if (!probe_data->cxl)
> + return;
> +
> + iounmap(probe_data->cxl->ctpio_cxl);
> +}
> +
> MODULE_IMPORT_NS("CXL");
> diff --git a/drivers/net/ethernet/sfc/efx_cxl.h b/drivers/net/ethernet/sfc/efx_cxl.h
> index 04e46278464d..3e2705cb063f 100644
> --- a/drivers/net/ethernet/sfc/efx_cxl.h
> +++ b/drivers/net/ethernet/sfc/efx_cxl.h
> @@ -20,10 +20,13 @@ struct efx_probe_data;
> struct efx_cxl {
> struct cxl_dev_state cxlds;
> struct cxl_memdev *cxlmd;
> + void __iomem *ctpio_cxl;
> };
>
> int efx_cxl_init(struct efx_probe_data *probe_data);
> +void efx_cxl_exit(struct efx_probe_data *probe_data);
> #else
> static inline int efx_cxl_init(struct efx_probe_data *probe_data) { return 0; }
> +static inline void efx_cxl_exit(struct efx_probe_data *probe_data) {}
> #endif
> #endif
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH v29 0/5] Type2 device basic support
From: Richard Cheng @ 2026-06-26 3:56 UTC (permalink / raw)
To: alejandro.lucero-palau
Cc: linux-cxl, netdev, dan.j.williams, edward.cree, davem, kuba,
pabeni, edumazet, dave.jiang, Alejandro Lucero
In-Reply-To: <20260622124010.2192888-1-alejandro.lucero-palau@amd.com>
On Mon, Jun 22, 2026 at 01:40:05PM +0800, alejandro.lucero-palau@amd.com wrote:
> From: Alejandro Lucero <alucerop@amd.com>
>
> This series adds the last bits for allowing a CXL Type2 driver to obtain
> a CXL region linked to the device HDM decoders committed by the BIOS,
> with the driver being the sfc network driver.
>
> Changes from v28:
>
> - patch 1:
> fix doc (Ed Cree)
> fix error path (Sashiko)
>
> - patch 3:
> removing extra + char (sashiko)
>
> - path5:
> remove stray change (Ed Cree)
>
> Changes from v27:
>
> - patch 1: make driver probe failing if error in efx_cxl_init (Dan)
> - patch 4: add unmapping if error after efx_cxl_init (Dave)
> - patch 4/5: move cxl_pio_initialised from patch 4 to patch 5 (Dave)
>
> Tested in the cxl_for_7.3 branch.
>
Hi Alejandro,
The series looks fine to me with one small question in patch 4.
I don't have the required NIC to test it, and not enough knowledge to
give a deep enough review, I can just say it LGTM at this point.
I'll leave for other guru to give tags.
Thanks for this.
Best regards,
Richard Cheng.
> Alejandro Lucero (5):
> sfc: add cxl support
> cxl/sfc: Map cxl regs
> cxl/sfc: Initialize dpa without a mailbox
> sfc: obtain and map cxl range using devm_cxl_probe_mem
> sfc: support pio mapping based on cxl
>
> drivers/cxl/core/core.h | 2 +
> drivers/cxl/core/mbox.c | 51 +------------
> drivers/cxl/core/memdev.c | 67 ++++++++++++++++
> drivers/cxl/core/pci.c | 1 +
> drivers/cxl/core/port.c | 1 +
> drivers/cxl/core/regs.c | 1 +
> drivers/cxl/cxlpci.h | 12 ---
> drivers/cxl/pci.c | 1 +
> drivers/net/ethernet/sfc/Kconfig | 9 +++
> drivers/net/ethernet/sfc/Makefile | 1 +
> drivers/net/ethernet/sfc/ef10.c | 41 ++++++++--
> drivers/net/ethernet/sfc/efx.c | 18 ++++-
> drivers/net/ethernet/sfc/efx_cxl.c | 105 ++++++++++++++++++++++++++
> drivers/net/ethernet/sfc/efx_cxl.h | 32 ++++++++
> drivers/net/ethernet/sfc/net_driver.h | 10 +++
> drivers/net/ethernet/sfc/nic.h | 3 +
> include/cxl/cxl.h | 2 +
> include/cxl/pci.h | 22 ++++++
> 18 files changed, 309 insertions(+), 70 deletions(-)
> create mode 100644 drivers/net/ethernet/sfc/efx_cxl.c
> create mode 100644 drivers/net/ethernet/sfc/efx_cxl.h
> create mode 100644 include/cxl/pci.h
>
>
> base-commit: 9b1e70e8f9ec4b5c6ce7fa774a0023bb6894c686
> --
> 2.34.1
>
>
^ permalink raw reply
* Re: [PATCH] octeontx2-af: Fix pci_dev reference leak in cgx_print_dmac_flt
From: Ratheesh Kannoth @ 2026-06-26 4:20 UTC (permalink / raw)
To: Wentao Liang
Cc: Sunil Goutham, Linu Cherian, Geetha sowjanya, hariprasad,
Subbaraya Sundeep, Andrew Lunn, David S . Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, netdev, linux-kernel, stable
In-Reply-To: <20260625063951.44361-1-vulab@iscas.ac.cn>
On 2026-06-25 at 12:09:51, Wentao Liang (vulab@iscas.ac.cn) wrote:
> In cgx_print_dmac_flt(), pci_get_device() is called to look up the AF
> PCI device, but its return value is passed directly to pci_get_drvdata()
> without saving the pointer. This means pci_dev_put() can never be called
> for the obtained device, causing a reference count leak.
>
> Fix it by saving the return value of pci_get_device() in a local variable
> and releasing it via pci_dev_put() after the drvdata is extracted.
>
> Cc: stable@vger.kernel.org
> Fixes: dbc52debf95f ("octeontx2-af: Debugfs support for DMAC filters")
> Signed-off-by: Wentao Liang <vulab@iscas.ac.cn>
> ---
> .../net/ethernet/marvell/octeontx2/af/rvu_debugfs.c | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c b/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
> index fa461489acdd..90dc13df9ff9 100644
> --- a/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
> +++ b/drivers/net/ethernet/marvell/octeontx2/af/rvu_debugfs.c
> @@ -2949,7 +2949,7 @@ RVU_DEBUG_SEQ_FOPS(cgx_stat, cgx_stat_display, NULL);
>
> static int cgx_print_dmac_flt(struct seq_file *s, int lmac_id)
> {
> - struct pci_dev *pdev = NULL;
> + struct pci_dev *af_pdev, *pdev = NULL;
> void *cgxd = s->private;
> char *bcast, *mcast;
> u16 index, domain;
> @@ -2958,8 +2958,13 @@ static int cgx_print_dmac_flt(struct seq_file *s, int lmac_id)
> u64 cfg, mac;
> int pf;
>
> - rvu = pci_get_drvdata(pci_get_device(PCI_VENDOR_ID_CAVIUM,
> - PCI_DEVID_OCTEONTX2_RVU_AF, NULL));
> + af_pdev = pci_get_device(PCI_VENDOR_ID_CAVIUM,
> + PCI_DEVID_OCTEONTX2_RVU_AF, NULL);
> + if (!af_pdev)
> + return -ENODEV;
> +
> + rvu = pci_get_drvdata(af_pdev);
> + pci_dev_put(af_pdev);
> if (!rvu)
> return -ENODEV;
Thanks for bringing this up! It looks like this issue was resolved in a previous commit:
469f4462ec83 ("octeontx2-af: fix CGX debugfs RVU AF PCI reference leaks").
>
> --
> 2.39.5 (Apple Git-154)
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox