* [PATCH] nfc: llcp: fix u8 offset truncation in LLCP TLV parsers
From: Lekë Hapçiu @ 2026-04-05 10:59 UTC (permalink / raw)
To: netdev
Cc: davem, edumazet, kuba, pabeni, horms, stable, linux-kernel,
Lekë Hapçiu
From: Lekë Hapçiu <framemain@outlook.com>
nfc_llcp_parse_gb_tlv() and nfc_llcp_parse_connection_tlv() declare
'offset' as u8, but compare it against a u16 tlv_array_len:
u8 type, length, offset = 0;
while (offset < tlv_array_len) { /* tlv_array_len is u16 */
...
offset += length + 2; /* wraps at 256 */
tlv += length + 2;
}
When tlv_array_len > 255 -- possible in nfc_llcp_parse_connection_tlv()
when the peer has negotiated MIUX = 0x7FF (MIU = 2175 bytes), so that
a CONNECT PDU can carry a TLV array of up to 2173 bytes -- the u8
offset wraps back below tlv_array_len after every 128 zero-length TLV
entries and the loop never terminates. The 'tlv' pointer meanwhile
advances without bound into adjacent kernel heap, causing:
* an OOB read of kernel heap content past the skb end;
* a kernel page fault / oops once 'tlv' leaves mapped memory.
This is reachable from any NFC P2P peer device within ~4 cm without
requiring compromised NFCC firmware.
Fix: promote 'offset' from u8 to u16 in both parsers, matching the
type of their tlv_array_len parameter.
nfc_llcp_parse_gb_tlv() takes GB bytes from the ATR_RES (max 44 bytes),
so the wrap cannot occur in practice there. Change it anyway for
correctness and to prevent copy-paste reintroduction.
Cc: stable@vger.kernel.org
Signed-off-by: Lekë Hapçiu <framemain@outlook.com>
---
net/nfc/llcp_commands.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/net/nfc/llcp_commands.c b/net/nfc/llcp_commands.c
index 291f26fac..6937dcb3b 100644
--- a/net/nfc/llcp_commands.c
+++ b/net/nfc/llcp_commands.c
@@ -193,7 +193,8 @@ int nfc_llcp_parse_gb_tlv(struct nfc_llcp_local *local,
const u8 *tlv_array, u16 tlv_array_len)
{
const u8 *tlv = tlv_array;
- u8 type, length, offset = 0;
+ u8 type, length;
+ u16 offset = 0;
pr_debug("TLV array length %d\n", tlv_array_len);
@@ -243,7 +244,8 @@ int nfc_llcp_parse_connection_tlv(struct nfc_llcp_sock *sock,
const u8 *tlv_array, u16 tlv_array_len)
{
const u8 *tlv = tlv_array;
- u8 type, length, offset = 0;
+ u8 type, length;
+ u16 offset = 0;
pr_debug("TLV array length %d\n", tlv_array_len);
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v4 0/9] driver core: Fix some race conditions
From: Danilo Krummrich @ 2026-04-05 12:02 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Douglas Anderson, Rafael J . Wysocki, Alan Stern, Saravana Kannan,
Christoph Hellwig, Eric Dumazet, Johan Hovold, Leon Romanovsky,
Alexander Lobakin, Alexey Kardashevskiy, Robin Murphy,
Andrew Morton, Frank.Li, Jason Gunthorpe, alex, alexander.stein,
andre.przywara, andrew, andrew, andriy.shevchenko, aou, ardb,
bhelgaas, brgl, broonie, catalin.marinas, chleroy, davem, david,
devicetree, dmaengine, driver-core, gbatra, gregory.clement,
hkallweit1, iommu, jirislaby, joel, joro, kees, kevin.brodsky,
kuba, lenb, lgirdwood, linux-acpi, linux-arm-kernel, linux-aspeed,
linux-cxl, linux-kernel, linux-mips, linux-mm, linux-pci,
linux-riscv, linux-serial, linux-snps-arc, linux-usb, linux,
linuxppc-dev, m.szyprowski, maddy, mani, maz, miko.lenczewski,
mpe, netdev, npiggin, osalvador, oupton, pabeni, palmer,
peter.ujfalusi, peterz, pjw, robh, sebastian.hesselbarth, tglx,
tsbogend, vgupta, vkoul, will, willy, yangyicong, yeoreum.yun
In-Reply-To: <2026040539-sponge-publisher-2b42@gregkh>
On Sun Apr 5, 2026 at 7:27 AM CEST, Greg Kroah-Hartman wrote:
> Anyway, this looks great, unless there are any objections, other than
> the "needs to be undefined", which a follow-on patch can handle, I'll
> queue them up next week for 7.1-rc1.
Sounds good, for the series:
Reviewed-by: Danilo Krummrich <dakr@kernel.org>
^ permalink raw reply
* [PATCH net v2] net: rose: stop timers before freeing neighbour in rose_neigh_put
From: Mashiro Chen @ 2026-04-05 12:58 UTC (permalink / raw)
To: davem, kuba
Cc: edumazet, horms, pabeni, linux-hams, linux-kernel, netdev,
syzbot+abd2b69348e2d9b107a1, Mashiro Chen
In-Reply-To: <20260403204459.124812-1-mashiro.chen@mailbox.org>
rose_neigh_put() frees the rose_neigh object when the reference count
reaches zero, but does not stop the t0timer and ftimer beforehand.
If a timer has been scheduled and fires after the object is freed,
the callback will access already-freed memory, leading to a
use-after-free.
For example, this can happen when rose_timer_expiry() in ROSE_STATE_2
calls rose_neigh_put() dropping the last reference while the
neighbour's t0timer is still pending:
rose_timer_expiry() (ROSE_STATE_2)
rose_neigh_put(rose->neighbour) --> refcount drops to 0, kfree
...
rose_t0timer_expiry() --> UAF: accesses freed neigh
Fix this by calling timer_delete_sync() for both t0timer and ftimer
in rose_neigh_put() before freeing the object. This ensures any
pending or running timer callback completes before the memory is
released.
This is safe because rose_neigh_put() is never called from the
neigh's own timer callbacks (t0timer_expiry / ftimer_expiry), so
timer_delete_sync() cannot deadlock.
The UAF can be triggered through the following sequence:
1. rose_add_node() creates a rose_neigh with refcount=2
(initial neigh_list reference plus one held by the new node entry)
2. A socket connects via rose_get_neigh(), rose_neigh_hold() raises
refcount to 3; rose_transmit_link() arms t0timer on the neigh
3. The routing entry is deleted: rose_del_node() drops the node
reference (3->2), calls rose_remove_neigh() which stops both
timers, then drops the neigh_list reference (2->1); the socket
now holds the only reference with t0timer stopped
4. T1 expires in ROSE_STATE_1: rose_timer_expiry() sends
CLEAR_REQUEST via rose_transmit_link(), which sees
neigh->restarted=0 and !rose_t0timer_running, and re-arms
t0timer on the neigh (refcount still 1)
5. T3 expires in ROSE_STATE_2: rose_timer_expiry() calls
rose_neigh_put(), refcount drops to 0, kfree(neigh)
6. t0timer fires, rose_t0timer_expiry() accesses freed neigh -> UAF
Fixes: d860d1faa6b2 ("net: rose: convert 'use' field to refcount_t")
Reported-by: syzbot+abd2b69348e2d9b107a1@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=abd2b69348e2d9b107a1
Signed-off-by: Mashiro Chen <mashiro.chen@mailbox.org>
---
include/net/rose.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/net/rose.h b/include/net/rose.h
index 2b5491bbf39ab..c69024e865456 100644
--- a/include/net/rose.h
+++ b/include/net/rose.h
@@ -160,6 +160,8 @@ static inline void rose_neigh_hold(struct rose_neigh *rose_neigh)
static inline void rose_neigh_put(struct rose_neigh *rose_neigh)
{
if (refcount_dec_and_test(&rose_neigh->use)) {
+ timer_delete_sync(&rose_neigh->t0timer);
+ timer_delete_sync(&rose_neigh->ftimer);
if (rose_neigh->ax25)
ax25_cb_put(rose_neigh->ax25);
kfree(rose_neigh->digipeat);
--
2.53.0
^ permalink raw reply related
* [PATCH v3 net-next] net: use get_random_u{16,32,64}() where appropriate
From: David Carlier @ 2026-04-05 15:48 UTC (permalink / raw)
To: Jakub Kicinski, David S . Miller, Eric Dumazet, Paolo Abeni
Cc: Andrew Lunn, Simon Horman, Ilya Dryomov, Johannes Berg,
Matthieu Baerts, Mat Martineau, Geliang Tang, Aaron Conole,
Ilya Maximets, Marcelo Ricardo Leitner, Xin Long, Jon Maloy,
netdev, ceph-devel, linux-wireless, mptcp, dev, linux-sctp,
tipc-discussion, linux-kernel, David Carlier
Use the typed random integer helpers instead of
get_random_bytes() when filling a single integer variable.
The helpers return the value directly, require no pointer
or size argument, and better express intent.
Skipped sites writing into __be16 fields (netdevsim) where
a direct assignment would trigger sparse endianness warnings.
Signed-off-by: David Carlier <devnexen@gmail.com>
---
drivers/net/netdevsim/psample.c | 4 ++--
net/ceph/auth_x.c | 2 +-
net/core/net_namespace.c | 2 +-
net/mac80211/mesh_plink.c | 2 +-
net/mptcp/subflow.c | 4 ++--
net/openvswitch/flow_table.c | 2 +-
net/sctp/sm_make_chunk.c | 4 ++--
net/tipc/node.c | 2 +-
8 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/net/netdevsim/psample.c b/drivers/net/netdevsim/psample.c
index 47d24bc64ee4..717d157c3ae2 100644
--- a/drivers/net/netdevsim/psample.c
+++ b/drivers/net/netdevsim/psample.c
@@ -94,7 +94,7 @@ static void nsim_dev_psample_md_prepare(const struct nsim_dev_psample *psample,
if (psample->out_tc_occ_max) {
u64 out_tc_occ;
- get_random_bytes(&out_tc_occ, sizeof(u64));
+ out_tc_occ = get_random_u64();
md->out_tc_occ = out_tc_occ & (psample->out_tc_occ_max - 1);
md->out_tc_occ_valid = 1;
}
@@ -102,7 +102,7 @@ static void nsim_dev_psample_md_prepare(const struct nsim_dev_psample *psample,
if (psample->latency_max) {
u64 latency;
- get_random_bytes(&latency, sizeof(u64));
+ latency = get_random_u64();
md->latency = latency & (psample->latency_max - 1);
md->latency_valid = 1;
}
diff --git a/net/ceph/auth_x.c b/net/ceph/auth_x.c
index 692e0b868822..936b43ae4a95 100644
--- a/net/ceph/auth_x.c
+++ b/net/ceph/auth_x.c
@@ -571,7 +571,7 @@ static int ceph_x_build_request(struct ceph_auth_client *ac,
blob = enc_buf + SHA256_DIGEST_SIZE;
}
- get_random_bytes(&auth->client_challenge, sizeof(u64));
+ auth->client_challenge = get_random_u64();
blob->client_challenge = auth->client_challenge;
blob->server_challenge = cpu_to_le64(xi->server_challenge);
diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
index 1057d16d5dd2..deb8b2ec5674 100644
--- a/net/core/net_namespace.c
+++ b/net/core/net_namespace.c
@@ -411,7 +411,7 @@ static __net_init int preinit_net(struct net *net, struct user_namespace *user_n
ref_tracker_dir_init(&net->refcnt_tracker, 128, "net_refcnt");
ref_tracker_dir_init(&net->notrefcnt_tracker, 128, "net_notrefcnt");
- get_random_bytes(&net->hash_mix, sizeof(u32));
+ net->hash_mix = get_random_u32();
net->dev_base_seq = 1;
net->user_ns = user_ns;
diff --git a/net/mac80211/mesh_plink.c b/net/mac80211/mesh_plink.c
index 803106fc3134..7cbab90c8784 100644
--- a/net/mac80211/mesh_plink.c
+++ b/net/mac80211/mesh_plink.c
@@ -712,7 +712,7 @@ void mesh_plink_timer(struct timer_list *t)
"Mesh plink for %pM (retry, timeout): %d %d\n",
sta->sta.addr, sta->mesh->plink_retries,
sta->mesh->plink_timeout);
- get_random_bytes(&rand, sizeof(u32));
+ rand = get_random_u32();
sta->mesh->plink_timeout = sta->mesh->plink_timeout +
rand % sta->mesh->plink_timeout;
++sta->mesh->plink_retries;
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index 5cfe19990f31..1a7736145dbc 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -72,7 +72,7 @@ static void subflow_req_create_thmac(struct mptcp_subflow_request_sock *subflow_
struct mptcp_sock *msk = subflow_req->msk;
u8 hmac[SHA256_DIGEST_SIZE];
- get_random_bytes(&subflow_req->local_nonce, sizeof(u32));
+ subflow_req->local_nonce = get_random_u32();
subflow_generate_hmac(READ_ONCE(msk->local_key),
READ_ONCE(msk->remote_key),
@@ -1639,7 +1639,7 @@ int __mptcp_subflow_connect(struct sock *sk, const struct mptcp_pm_local *local,
ssk = sf->sk;
subflow = mptcp_subflow_ctx(ssk);
do {
- get_random_bytes(&subflow->local_nonce, sizeof(u32));
+ subflow->local_nonce = get_random_u32();
} while (!subflow->local_nonce);
/* if 'IPADDRANY', the ID will be set later, after the routing */
diff --git a/net/openvswitch/flow_table.c b/net/openvswitch/flow_table.c
index 61c6a5f77c2e..67d5b8c0fe79 100644
--- a/net/openvswitch/flow_table.c
+++ b/net/openvswitch/flow_table.c
@@ -167,7 +167,7 @@ static struct table_instance *table_instance_alloc(int new_size)
ti->n_buckets = new_size;
ti->node_ver = 0;
- get_random_bytes(&ti->hash_seed, sizeof(u32));
+ ti->hash_seed = get_random_u32();
return ti;
}
diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
index 2c0017d058d4..de86ac088289 100644
--- a/net/sctp/sm_make_chunk.c
+++ b/net/sctp/sm_make_chunk.c
@@ -2727,7 +2727,7 @@ __u32 sctp_generate_tag(const struct sctp_endpoint *ep)
__u32 x;
do {
- get_random_bytes(&x, sizeof(__u32));
+ x = get_random_u32();
} while (x == 0);
return x;
@@ -2738,7 +2738,7 @@ __u32 sctp_generate_tsn(const struct sctp_endpoint *ep)
{
__u32 retval;
- get_random_bytes(&retval, sizeof(__u32));
+ retval = get_random_u32();
return retval;
}
diff --git a/net/tipc/node.c b/net/tipc/node.c
index af442a5ef8f3..97aa970a0d83 100644
--- a/net/tipc/node.c
+++ b/net/tipc/node.c
@@ -1275,7 +1275,7 @@ void tipc_node_check_dest(struct net *net, u32 addr,
goto exit;
if_name = strchr(b->name, ':') + 1;
- get_random_bytes(&session, sizeof(u16));
+ session = get_random_u16();
if (!tipc_link_create(net, if_name, b->identity, b->tolerance,
b->net_plane, b->mtu, b->priority,
b->min_win, b->max_win, session,
--
2.53.0
^ permalink raw reply related
* Re: [PATCH net 1/1] net: l3mdev: Ignore non-L3 uppers in l3mdev_fib_table_rcu
From: David Ahern @ 2026-04-05 16:22 UTC (permalink / raw)
To: Ao Zhou, netdev
Cc: David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman, Yifan Wu, Juefei Pu, Yuan Tan, Xin Liu, Haoze Xie
In-Reply-To: <b3b88cddc7e79d4b43756b26ae5db965678f3ba9.1775062214.git.royenheart@gmail.com>
On 4/4/26 5:52 AM, Ao Zhou wrote:
> From: Haoze Xie <royenheart@gmail.com>
>
> l3mdev_fib_table_rcu() assumes that any upper device observed for
> an IFF_L3MDEV_SLAVE device is an L3 master and dereferences
> master->l3mdev_ops unconditionally.
>
> VRF slave setup sets IFF_L3MDEV_SLAVE before the upper link is fully
> switched, so readers can transiently observe a non-L3 upper such as a
> bridge and follow a NULL l3mdev_ops pointer. Require the current upper
> to still be an L3 master before consulting its FIB table.
>
> Fixes: fee6d4c777a1 ("net: Add netif_is_l3_slave")
Fixes should be:
commit fdeea7be88b12742bfd50d9e19a06c0d2e702400
Author: Ido Schimmel <idosch@mellanox.com>
Date: Thu Mar 16 09:08:15 2017 +0100
net: vrf: Set slave's private flag before linking
> Reported-by: Yifan Wu <yifanwucs@gmail.com>
> Reported-by: Juefei Pu <tomapufckgml@gmail.com>
> Co-developed-by: Yuan Tan <yuantan098@gmail.com>
> Signed-off-by: Yuan Tan <yuantan098@gmail.com>
> Suggested-by: Xin Liu <bird@lzu.edu.cn>
> Signed-off-by: Haoze Xie <royenheart@gmail.com>
> Signed-off-by: Ao Zhou <n05ec@lzu.edu.cn>
> ---
> net/l3mdev/l3mdev.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/net/l3mdev/l3mdev.c b/net/l3mdev/l3mdev.c
> index 5432a5f2dfc8..b8a3030cb2c4 100644
> --- a/net/l3mdev/l3mdev.c
> +++ b/net/l3mdev/l3mdev.c
> @@ -177,7 +177,7 @@ u32 l3mdev_fib_table_rcu(const struct net_device *dev)
> const struct net_device *master;
>
> master = netdev_master_upper_dev_get_rcu(_dev);
> - if (master &&
> + if (master && netif_is_l3_master(master) &&
Reviewed-by: David Ahern <dsahern@kernel.org>
^ permalink raw reply
* Re: [PATCH iproute2-next] ss: add support for TCP delack timers
From: patchwork-bot+netdevbpf @ 2026-04-05 16:30 UTC (permalink / raw)
To: Eric Dumazet
Cc: dsahern, stephen, davem, kuba, pabeni, ncardwell, kuniyu, netdev,
eric.dumazet
In-Reply-To: <20260403102309.338648-1-edumazet@google.com>
Hello:
This patch was applied to iproute2/iproute2-next.git (main)
by David Ahern <dsahern@kernel.org>:
On Fri, 3 Apr 2026 10:23:09 +0000 you wrote:
> Kernel commit c698f5cc940d ("inet_diag: report delayed ack timer information")
> added a new enum for idiag_timer values and support for delayed ack timers.
>
> Change tcp_timer_print() to use the new enum and display "delack"
> instead of "unknown":
>
> tt -to
> ...
> ESTAB 10 0 [2002:a05:6830:1f86::]:12875 [2002:a05:6830:1f85::]:50438
>
> [...]
Here is the summary with links:
- [iproute2-next] ss: add support for TCP delack timers
https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=37c010d59a44
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 iproute2-next] dpll: add direction and state filtering for pin show
From: patchwork-bot+netdevbpf @ 2026-04-05 16:30 UTC (permalink / raw)
To: Petr Oros; +Cc: netdev, dsahern, stephen, ivecera
In-Reply-To: <20260331135918.49567-1-poros@redhat.com>
Hello:
This patch was applied to iproute2/iproute2-next.git (main)
by David Ahern <dsahern@kernel.org>:
On Tue, 31 Mar 2026 15:59:18 +0200 you wrote:
> Allow filtering pins by direction (input/output) and state
> (connected/disconnected/selectable) in the pin show command.
> These filters match against parent-device nested attributes and
> can be combined with the parent-device filter to check a specific
> parent-device relationship.
>
> Example: dpll pin show parent-device 0 direction input state connected
> Signed-off-by: Petr Oros <poros@redhat.com>
>
> [...]
Here is the summary with links:
- [iproute2-next] dpll: add direction and state filtering for pin show
https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=90a9c94bdb79
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 iproute2-next 0/2] tc/tbf and tc/htb: Allow 64 bit burst
From: patchwork-bot+netdevbpf @ 2026-04-05 16:40 UTC (permalink / raw)
To: Ioana Lazea; +Cc: netdev, jhs, stephen, dsahern, jay.vosburgh
In-Reply-To: <20260323092918.11010-1-ioana.lazea@canonical.com>
Hello:
This series was applied to iproute2/iproute2-next.git (main)
by David Ahern <dsahern@kernel.org>:
On Mon, 23 Mar 2026 09:29:11 +0000 you wrote:
> This patchset updates the TBF and HTB queuing discipline
> configurations to support burst sizes beyond the legacy 32-bit limits.
> As network interface speeds increase, the kernel’s internal
> representation of burst (calculated as time at a specific rate) can
> easily exceed the 4 GB threshold. These changes enable userspace to
> accommodate these larger values where the kernel API allows.
>
> [...]
Here is the summary with links:
- [iproute2-next,1/2] tc/tbf: enable use of 64 bit burst
https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=063071c4a8ba
- [iproute2-next,2/2] tc/htb: enable use of 64 bit burst
https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=f6cb25efa1b2
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* [PATCH] nfc: llcp: fix missing return after LLCP_CLOSED check in recv_hdlc and recv_disc
From: Lekë Hapçiu @ 2026-04-05 16:41 UTC (permalink / raw)
To: netdev; +Cc: linux-nfc, davem, kuba, krzysztof.kozlowski, stable
From: Lekë Hapçiu <framemain@outlook.com>
nfc_llcp_recv_hdlc() and nfc_llcp_recv_disc() both call
nfc_llcp_sock_get() (which increments the socket reference count) and
lock_sock() before processing incoming PDUs. When the socket is found
to be in state LLCP_CLOSED both functions correctly call release_sock()
and nfc_llcp_sock_put() to undo those operations, but are missing a
return statement:
lock_sock(sk);
if (sk->sk_state == LLCP_CLOSED) {
release_sock(sk);
nfc_llcp_sock_put(llcp_sock);
/* ← return missing */
}
/* Falls through with lock released and reference dropped */
...
release_sock(sk); /* double unlock */
nfc_llcp_sock_put(llcp_sock); /* double put → refcount underflow */
The fall-through causes three independent bugs:
1. Use-after-free: all llcp_sock field accesses after the LLCP_CLOSED
block occur with the socket lock released and the reference dropped;
another CPU may free the socket concurrently.
2. Double release_sock: sk_lock.owned is already 0 — LOCKDEP reports
"WARNING: suspicious unlock balance detected".
3. Double nfc_llcp_sock_put: the refcount is decremented a second time
at the end of the function, potentially driving it below zero
(refcount_t underflow), corrupting the SLUB freelist and causing a
subsequent use-after-free or double-free.
Both functions are reachable from any NFC P2P peer within physical
proximity (~4 cm) without hostile NFCC firmware:
- nfc_llcp_recv_hdlc: triggered by sending an LLCP I, RR, or RNR PDU
to a SAP pair whose connection has been torn down.
- nfc_llcp_recv_disc: triggered by sending an LLCP DISC PDU to a SAP
pair that is already in LLCP_CLOSED state.
Fix: add the missing return statement in both functions so that the
LLCP_CLOSED branch exits after cleanup.
Fixes: Introduced with nfc_llcp_recv_hdlc / nfc_llcp_recv_disc
Signed-off-by: Lekë Hapçiu <framemain@outlook.com>
---
net/nfc/llcp_core.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/nfc/llcp_core.c b/net/nfc/llcp_core.c
index 366d75663..db5bc6a87 100644
--- a/net/nfc/llcp_core.c
+++ b/net/nfc/llcp_core.c
@@ -1091,6 +1091,7 @@ static void nfc_llcp_recv_hdlc(struct nfc_llcp_local *local,
if (sk->sk_state == LLCP_CLOSED) {
release_sock(sk);
nfc_llcp_sock_put(llcp_sock);
+ return;
}
/* Pass the payload upstream */
@@ -1182,6 +1183,7 @@ static void nfc_llcp_recv_disc(struct nfc_llcp_local *local,
if (sk->sk_state == LLCP_CLOSED) {
release_sock(sk);
nfc_llcp_sock_put(llcp_sock);
+ return;
}
if (sk->sk_state == LLCP_CONNECTED) {
--
2.51.0
^ permalink raw reply related
* Re: [PATCH v2 iproute2-next 0/4] Introduce FRMR pools
From: David Ahern @ 2026-04-05 17:09 UTC (permalink / raw)
To: Chiara Meiohas, leon, stephen; +Cc: michaelgur, jgg, linux-rdma, netdev
In-Reply-To: <20260330173118.766885-1-cmeiohas@nvidia.com>
On 3/30/26 11:31 AM, Chiara Meiohas wrote:
> From Michael:
>
> This series adds support for managing Fast Registration Memory Region
> (FRMR) pools in rdma tool, enabling users to monitor and configure FRMR
> pool behavior.
>
> FRMR pools are used to cache and reuse Fast Registration Memory Region
> handles to improve performance by avoiding the overhead of repeated
> memory region creation and destruction. This series introduces commands
> to view FRMR pool statistics and configure pool parameters such as
> aging time and pinned handle count.
>
> The 'show' command allows users to display FRMR pools created on
> devices, their properties, and usage statistics. Each pool is identified
> by a unique key (hex-encoded properties) for easy reference in
> subsequent operations.
>
> The aging 'set' command allows users to modify the aging time parameter,
> which controls how long unused FRMR handles remain in the pool before
> being released.
>
> The pinned 'set' command allows users to configure the number of pinned
> handles in a pool. Pinned handles are exempt from aging and remain
> permanently available for reuse, which is useful for workloads with
> predictable memory region usage patterns.
>
> Command usage and examples are included in the commits and man pages.
>
> These patches are complimentary to the kernel patches:
> https://lore.kernel.org/linux-rdma/20260226-frmr_pools-v4-0-95360b54f15e@nvidia.com/
>
applied after fixing up a few nits.
Please clone the ai review prompts from:
https://github.com/masoncl/review-prompts.git
Run the setup scripts and have ai review patches before sending. This
should really be part of both kernel and iproute2 development workflow now.
^ permalink raw reply
* Re: [PATCH v2 iproute2-next 0/4] Introduce FRMR pools
From: patchwork-bot+netdevbpf @ 2026-04-05 17:10 UTC (permalink / raw)
To: Chiara Meiohas
Cc: leon, dsahern, stephen, michaelgur, jgg, linux-rdma, netdev
In-Reply-To: <20260330173118.766885-1-cmeiohas@nvidia.com>
Hello:
This series was applied to iproute2/iproute2-next.git (main)
by David Ahern <dsahern@kernel.org>:
On Mon, 30 Mar 2026 20:31:14 +0300 you wrote:
> From Michael:
>
> This series adds support for managing Fast Registration Memory Region
> (FRMR) pools in rdma tool, enabling users to monitor and configure FRMR
> pool behavior.
>
> FRMR pools are used to cache and reuse Fast Registration Memory Region
> handles to improve performance by avoiding the overhead of repeated
> memory region creation and destruction. This series introduces commands
> to view FRMR pool statistics and configure pool parameters such as
> aging time and pinned handle count.
>
> [...]
Here is the summary with links:
- [v2,iproute2-next,1/4] rdma: Update headers
https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=93368ee34528
- [v2,iproute2-next,2/4] rdma: Add resource FRMR pools show command
(no matching commit)
- [v2,iproute2-next,3/4] rdma: Add FRMR pools set aging command
https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=26c8bc1e6563
- [v2,iproute2-next,4/4] rdma: Add FRMR pools set pinned command
(no matching commit)
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Discover How To Instantly Rank On Top Of Every Search From Google Rankings To AI Discovery In ChatGPT, Gemini, Claude, Perplexity, & Copilot Confirmation
From: Zoom Webinar @ 2026-04-05 17:14 UTC (permalink / raw)
To: netdev
[-- Attachment #1.1: Type: text/html, Size: 23811 bytes --]
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1.2: Type: text/calendar; method=REQUEST;; charset=UTF-8, Size: 3178 bytes --]
BEGIN:VCALENDAR
PRODID:-//zoom.us//iCalendar Event//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
LAST-MODIFIED:20260306T231828Z
TZURL:https://www.tzurl.org/zoneinfo-outlook/America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20260405T162408Z
DTSTART;TZID=America/New_York:20260405T150000
DTEND;TZID=America/New_York:20260405T160000
SUMMARY:Discover How To Instantly Rank On Top Of Every Search From Google Rankings To AI Discovery In ChatGPT\, Gemini\, Claude\, Perplexity\, & Copilot
UID:b97kuj9o70pj0c9k6sq36e1gdpin8p35ep07cpr5e8n6mpbidpimobjfe9jg
TZID:America/New_York
DESCRIPTION:Topic: Discover How To Instantly Rank On Top Of Every Search From Google Rankings To AI Discovery In ChatGPT\, Gemini\, Claude\, Perplexity\, & Copilot\nDescription: BONUS: Get The World's First AI Agent That Builds\, Runs & Monetizes A Complete Faceless YouTube Channel. Press ONE Button… And Watch ChannelAgent Research Your Niche\, Write Your Scripts\, Record Your Voiceovers\, Create 10-50 Videos at go\, Design Your Thumbnails\, Handle Your SEO\, Upload To YouTube\, AND Monetize Everything… All On Complete Autopilot. Click here https://lik.wiki/get-y0utube-payments\n\nNOTE: If you don't want future invitation to our special trainings kindly send an email with the subject "END'' to adah43397@gmail.com\n\nJoin from PC\, Mac\, iPad\, or Android:\nhttps://us06web.zoom.us/w/88301474380?tk=SrHeUFs3vbF4Eysn9CDjs0cMJBylMSqQsGc3bD0AGYM.DQkAAAAUjy2STBZCZVI0bEJrMlQ5UzhyS3poZnI4bExRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&pwd=pXWLcjEPli4qoHjpmE6NdMLS1IwIMQ.1&uuid=WN_XX_nL7sISOu84_gZN3aKLg\nPasscode:620874\n\nPhone one-tap:\n+16469313860\,\,88301474380#\,\,\,\,*620874# US\n+16694449171\,\,88301474380#\,\,\,\,*620874# US\n\nJoin via audio:\n+1 646 931 3860 US\n+1 669 444 9171 US\n+1 669 900 6833 US (San Jose)\n+1 689 278 1000 US\n+1 719 359 4580 US\n+1 253 205 0468 US\n+1 253 215 8782 US (Tacoma)\n+1 301 715 8592 US (Washington DC)\n+1 305 224 1968 US\n+1 309 205 3325 US\n+1 312 626 6799 US (Chicago)\n+1 346 248 7799 US (Houston)\n+1 360 209 5623 US\n+1 386 347 5053 US\n+1 507 473 4847 US\n+1 564 217 2000 US\n+1 646 558 8656 US (New York)\nWebinar ID: 883 0147 4380\nPasscode: 620874\nInternational numbers available: https://us06web.zoom.us/u/kdkwhB46zb\n\n\n
LOCATION:https://us06web.zoom.us/w/88301474380?tk=SrHeUFs3vbF4Eysn9CDjs0cMJBylMSqQsGc3bD0AGYM.DQkAAAAUjy2STBZCZVI0bEJrMlQ5UzhyS3poZnI4bExRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&pwd=pXWLcjEPli4qoHjpmE6NdMLS1IwIMQ.1&uuid=WN_XX_nL7sISOu84_gZN3aKLg
SEQUENCE:1775405209
ORGANIZER;ROLE=REQ-PARTICIPANT;CN=Zoom Webinar:no-reply@zoom.us
ATTENDEE;ROLE=REQ-PARTICIPANT;CN=netdev@vger.kernel.org:mailto:netdev@vger.kernel.org
BEGIN:VALARM
TRIGGER:-PT10M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: invite.ics --]
[-- Type: text/calendar; name="invite.ics", Size: 3178 bytes --]
BEGIN:VCALENDAR
PRODID:-//zoom.us//iCalendar Event//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
LAST-MODIFIED:20260306T231828Z
TZURL:https://www.tzurl.org/zoneinfo-outlook/America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZNAME:EDT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
DTSTART:19700308T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZNAME:EST
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
DTSTART:19701101T020000
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTAMP:20260405T162408Z
DTSTART;TZID=America/New_York:20260405T150000
DTEND;TZID=America/New_York:20260405T160000
SUMMARY:Discover How To Instantly Rank On Top Of Every Search From Google Rankings To AI Discovery In ChatGPT\, Gemini\, Claude\, Perplexity\, & Copilot
UID:b97kuj9o70pj0c9k6sq36e1gdpin8p35ep07cpr5e8n6mpbidpimobjfe9jg
TZID:America/New_York
DESCRIPTION:Topic: Discover How To Instantly Rank On Top Of Every Search From Google Rankings To AI Discovery In ChatGPT\, Gemini\, Claude\, Perplexity\, & Copilot\nDescription: BONUS: Get The World's First AI Agent That Builds\, Runs & Monetizes A Complete Faceless YouTube Channel. Press ONE Button… And Watch ChannelAgent Research Your Niche\, Write Your Scripts\, Record Your Voiceovers\, Create 10-50 Videos at go\, Design Your Thumbnails\, Handle Your SEO\, Upload To YouTube\, AND Monetize Everything… All On Complete Autopilot. Click here https://lik.wiki/get-y0utube-payments\n\nNOTE: If you don't want future invitation to our special trainings kindly send an email with the subject "END'' to adah43397@gmail.com\n\nJoin from PC\, Mac\, iPad\, or Android:\nhttps://us06web.zoom.us/w/88301474380?tk=SrHeUFs3vbF4Eysn9CDjs0cMJBylMSqQsGc3bD0AGYM.DQkAAAAUjy2STBZCZVI0bEJrMlQ5UzhyS3poZnI4bExRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&pwd=pXWLcjEPli4qoHjpmE6NdMLS1IwIMQ.1&uuid=WN_XX_nL7sISOu84_gZN3aKLg\nPasscode:620874\n\nPhone one-tap:\n+16469313860\,\,88301474380#\,\,\,\,*620874# US\n+16694449171\,\,88301474380#\,\,\,\,*620874# US\n\nJoin via audio:\n+1 646 931 3860 US\n+1 669 444 9171 US\n+1 669 900 6833 US (San Jose)\n+1 689 278 1000 US\n+1 719 359 4580 US\n+1 253 205 0468 US\n+1 253 215 8782 US (Tacoma)\n+1 301 715 8592 US (Washington DC)\n+1 305 224 1968 US\n+1 309 205 3325 US\n+1 312 626 6799 US (Chicago)\n+1 346 248 7799 US (Houston)\n+1 360 209 5623 US\n+1 386 347 5053 US\n+1 507 473 4847 US\n+1 564 217 2000 US\n+1 646 558 8656 US (New York)\nWebinar ID: 883 0147 4380\nPasscode: 620874\nInternational numbers available: https://us06web.zoom.us/u/kdkwhB46zb\n\n\n
LOCATION:https://us06web.zoom.us/w/88301474380?tk=SrHeUFs3vbF4Eysn9CDjs0cMJBylMSqQsGc3bD0AGYM.DQkAAAAUjy2STBZCZVI0bEJrMlQ5UzhyS3poZnI4bExRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&pwd=pXWLcjEPli4qoHjpmE6NdMLS1IwIMQ.1&uuid=WN_XX_nL7sISOu84_gZN3aKLg
SEQUENCE:1775405209
ORGANIZER;ROLE=REQ-PARTICIPANT;CN=Zoom Webinar:no-reply@zoom.us
ATTENDEE;ROLE=REQ-PARTICIPANT;CN=netdev@vger.kernel.org:mailto:netdev@vger.kernel.org
BEGIN:VALARM
TRIGGER:-PT10M
ACTION:DISPLAY
DESCRIPTION:Reminder
END:VALARM
END:VEVENT
END:VCALENDAR
^ permalink raw reply
* Re: [PATCH iproute2-next v2] dpll: Send object per event in JSON monitor mode
From: patchwork-bot+netdevbpf @ 2026-04-05 17:30 UTC (permalink / raw)
To: Vitaly Grinberg; +Cc: netdev, stephen
In-Reply-To: <20260329-dpll-mon-j-v2-1-c8170a80e6d8@redhat.com>
Hello:
This patch was applied to iproute2/iproute2-next.git (main)
by David Ahern <dsahern@kernel.org>:
On Sun, 29 Mar 2026 10:51:01 +0300 you wrote:
> Previously, monitor mode wrapped all events in a single JSON array
> inside a top-level object, which made piping the output to external
> tools (such as `jq`) impossible.
> Send a separate JSON object for each event in monitor mode,
> making the output suitable for line-by-line consumers. Skip the
> global JSON wrapper for monitor mode.
>
> [...]
Here is the summary with links:
- [iproute2-next,v2] dpll: Send object per event in JSON monitor mode
https://git.kernel.org/pub/scm/network/iproute2/iproute2-next.git/commit/?id=52204702bde3
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] rxrpc/proc: size address buffers for %pISpc output
From: Anderson Nascimento @ 2026-04-05 17:40 UTC (permalink / raw)
To: Pengpeng Hou, David Howells, Marc Dionne
Cc: Eric Dumazet, Jakub Kicinski, Paolo Abeni, Simon Horman,
linux-afs, netdev, linux-kernel
In-Reply-To: <20260404190004.4-rxrpc-proc-pengpeng@iscas.ac.cn>
On 4/4/26 6:32 AM, Pengpeng Hou wrote:
> The AF_RXRPC procfs helpers format local and remote socket addresses into
> fixed 50-byte stack buffers with "%pISpc".
>
> That is too small for the longest IPv6-with-port form the formatter can
> produce: a compressed IPv6 address still permits a bracketed mapped-IPv4
> spelling plus the trailing port, which exceeds 50 bytes including the final
> NUL.
>
> Size the buffers from the formatters maximum textual form and switch the
> call sites to scnprintf().
>
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> net/rxrpc/proc.c | 32 ++++++++++++++++++--------------
> 1 file changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/net/rxrpc/proc.c b/net/rxrpc/proc.c
> index 59292f7f9205..7925d4569776 100644
> --- a/net/rxrpc/proc.c
> +++ b/net/rxrpc/proc.c
> @@ -10,6 +10,10 @@
> #include <net/af_rxrpc.h>
> #include "ar-internal.h"
>
> +#define RXRPC_PROC_ADDRBUF_SIZE \
> + (sizeof("[xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:255.255.255.255]") + \
> + sizeof(":12345"))
> +
> static const char *const rxrpc_conn_states[RXRPC_CONN__NR_STATES] = {
> [RXRPC_CONN_UNUSED] = "Unused ",
> [RXRPC_CONN_CLIENT_UNSECURED] = "ClUnsec ",
> @@ -53,7 +57,7 @@ static int rxrpc_call_seq_show(struct seq_file *seq, void *v)
> struct rxrpc_net *rxnet = rxrpc_net(seq_file_net(seq));
> enum rxrpc_call_state state;
> rxrpc_seq_t tx_bottom;
> - char lbuff[50], rbuff[50];
> + char lbuff[RXRPC_PROC_ADDRBUF_SIZE], rbuff[RXRPC_PROC_ADDRBUF_SIZE];
> long timeout = 0;
>
> if (v == &rxnet->calls) {
> @@ -69,11 +73,11 @@ static int rxrpc_call_seq_show(struct seq_file *seq, void *v)
>
> local = call->local;
> if (local)
> - sprintf(lbuff, "%pISpc", &local->srx.transport);
> + scnprintf(lbuff, sizeof(lbuff), "%pISpc", &local->srx.transport);
> else
> strcpy(lbuff, "no_local");
>
> - sprintf(rbuff, "%pISpc", &call->dest_srx.transport);
> + scnprintf(rbuff, sizeof(rbuff), "%pISpc", &call->dest_srx.transport);
>
> state = rxrpc_call_state(call);
> if (state != RXRPC_CALL_SERVER_PREALLOC)
> @@ -142,7 +146,7 @@ static int rxrpc_connection_seq_show(struct seq_file *seq, void *v)
> struct rxrpc_connection *conn;
> struct rxrpc_net *rxnet = rxrpc_net(seq_file_net(seq));
> const char *state;
> - char lbuff[50], rbuff[50];
> + char lbuff[RXRPC_PROC_ADDRBUF_SIZE], rbuff[RXRPC_PROC_ADDRBUF_SIZE];
>
> if (v == &rxnet->conn_proc_list) {
> seq_puts(seq,
> @@ -161,8 +165,8 @@ static int rxrpc_connection_seq_show(struct seq_file *seq, void *v)
> goto print;
> }
>
> - sprintf(lbuff, "%pISpc", &conn->local->srx.transport);
> - sprintf(rbuff, "%pISpc", &conn->peer->srx.transport);
> + scnprintf(lbuff, sizeof(lbuff), "%pISpc", &conn->local->srx.transport);
> + scnprintf(rbuff, sizeof(rbuff), "%pISpc", &conn->peer->srx.transport);
> print:
> state = rxrpc_is_conn_aborted(conn) ?
> rxrpc_call_completions[conn->completion] :
> @@ -228,7 +232,7 @@ static int rxrpc_bundle_seq_show(struct seq_file *seq, void *v)
> {
> struct rxrpc_bundle *bundle;
> struct rxrpc_net *rxnet = rxrpc_net(seq_file_net(seq));
> - char lbuff[50], rbuff[50];
> + char lbuff[RXRPC_PROC_ADDRBUF_SIZE], rbuff[RXRPC_PROC_ADDRBUF_SIZE];
>
> if (v == &rxnet->bundle_proc_list) {
> seq_puts(seq,
> @@ -242,8 +246,8 @@ static int rxrpc_bundle_seq_show(struct seq_file *seq, void *v)
>
> bundle = list_entry(v, struct rxrpc_bundle, proc_link);
>
> - sprintf(lbuff, "%pISpc", &bundle->local->srx.transport);
> - sprintf(rbuff, "%pISpc", &bundle->peer->srx.transport);
> + scnprintf(lbuff, sizeof(lbuff), "%pISpc", &bundle->local->srx.transport);
> + scnprintf(rbuff, sizeof(rbuff), "%pISpc", &bundle->peer->srx.transport);
> seq_printf(seq,
> "UDP %-47.47s %-47.47s %4x %3u %3d"
> " %c%c%c %08x | %08x %08x %08x %08x %08x\n",
> @@ -279,7 +283,7 @@ static int rxrpc_peer_seq_show(struct seq_file *seq, void *v)
> {
> struct rxrpc_peer *peer;
> time64_t now;
> - char lbuff[50], rbuff[50];
> + char lbuff[RXRPC_PROC_ADDRBUF_SIZE], rbuff[RXRPC_PROC_ADDRBUF_SIZE];
>
> if (v == SEQ_START_TOKEN) {
> seq_puts(seq,
> @@ -290,9 +294,9 @@ static int rxrpc_peer_seq_show(struct seq_file *seq, void *v)
>
> peer = list_entry(v, struct rxrpc_peer, hash_link);
>
> - sprintf(lbuff, "%pISpc", &peer->local->srx.transport);
> + scnprintf(lbuff, sizeof(lbuff), "%pISpc", &peer->local->srx.transport);
>
> - sprintf(rbuff, "%pISpc", &peer->srx.transport);
> + scnprintf(rbuff, sizeof(rbuff), "%pISpc", &peer->srx.transport);
>
> now = ktime_get_seconds();
> seq_printf(seq,
> @@ -401,7 +405,7 @@ const struct seq_operations rxrpc_peer_seq_ops = {
> static int rxrpc_local_seq_show(struct seq_file *seq, void *v)
> {
> struct rxrpc_local *local;
> - char lbuff[50];
> + char lbuff[RXRPC_PROC_ADDRBUF_SIZE];
>
> if (v == SEQ_START_TOKEN) {
> seq_puts(seq,
> @@ -412,7 +416,7 @@ static int rxrpc_local_seq_show(struct seq_file *seq, void *v)
>
> local = hlist_entry(v, struct rxrpc_local, link);
>
> - sprintf(lbuff, "%pISpc", &local->srx.transport);
> + scnprintf(lbuff, sizeof(lbuff), "%pISpc", &local->srx.transport);
>
> seq_printf(seq,
> "UDP %-47.47s %3u %3u %3u\n",
Do you have any evidence to confirm this issue? While the code could be
improved, I don't see how that specific error would occur. Based on a
quick experiment, the resulting string is at most 47 or 48 bytes (e.g.,
|[ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff]:65535|).
^ permalink raw reply
* Re: [PATCH v2 iproute2-next 0/4] Introduce FRMR pools
From: Chiara Meiohas @ 2026-04-05 17:44 UTC (permalink / raw)
To: David Ahern, leon, stephen; +Cc: michaelgur, jgg, linux-rdma, netdev
In-Reply-To: <a441f862-1ebe-4fd9-9ef5-aac718fb008c@gmail.com>
On 05/04/2026 20:09, David Ahern wrote:
> applied after fixing up a few nits.
>
> Please clone the ai review prompts from:
> https://github.com/masoncl/review-prompts.git
>
> Run the setup scripts and have ai review patches before sending. This
> should really be part of both kernel and iproute2 development workflow now.
Thanks for the note. Sorry I missed that — I’ll run those review prompts before
sending the next patchset.
Chiara
^ permalink raw reply
* [net-next v38] mctp pcc: Implement MCTP over PCC Transport
From: Adam Young @ 2026-04-05 18:07 UTC (permalink / raw)
To: Jeremy Kerr, Matt Johnston, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
Cc: netdev, linux-kernel, Sudeep Holla, Jonathan Cameron, Huisong Li
Implementation of network driver for
Management Component Transport Protocol(MCTP)
over Platform Communication Channel(PCC)
DMTF DSP:0292
Link: https://www.dmtf.org/sites/default/files/standards/documents/DSP0292_1.0.0WIP50.pdf
The transport mechanism is called Platform Communication Channels (PCC)
is part of the ACPI spec:
Link: https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/14_Platform_Communications_Channel/Platform_Comm_Channel.html
The PCC mechanism is managed via a mailbox implemented at
drivers/mailbox/pcc.c
MCTP devices are specified via ACPI by entries in DSDT/SSDT and
reference channels specified in the PCCT. Messages are sent on a type
3 and received on a type 4 channel. Communication with other devices
use the PCC based doorbell mechanism; a shared memory segment with a
corresponding interrupt and a memory register used to trigger remote
interrupts.
The shared buffer must be at least 68 bytes long as that is the minimum
MTU as defined by the MCTP specification.
Unlike the existing PCC Type 2 based drivers, the mssg parameter to
mbox_send_msg is actively used. The data section of the struct sk_buff
that contains the outgoing packet is sent to the mailbox, already
properly formatted as a PCC exctended message.
If the mailbox ring buffer is full, the driver stops the incoming
packet queues until a message has been sent, freeing space in the
ring buffer.
When the Type 3 channel outbox receives a txdone response interrupt,
it consumes the outgoing sk_buff, allowing it to be freed.
Bringing up an interface creates the channel between the network driver
and the mailbox driver. This enables communication with the remote
endpoint, to include the receipt of new messages. Bringing down an
interface removes the channel, and no new messages can be delivered.
Stopping the interface will leave any packets that are cached in the
mailbox ringbuffer. They cannot safely be freed until the PCC mailbox
attempts to deliver them and has removed them from the ring buffer.
PCC is based on a shared buffer and a set of I/O mapped memory locations
that the Spec calls registers. This mechanism exists regardless of the
existence of the driver. If the user has the ability to map these
physical location to virtual locations, they have the ability to drive the
hardware. Thus, there is a security aspect to this mechanism that extends
beyond the responsibilities of the operating system.
If the hardware does not expose the PCC in the ACPI table, this device
will never be enabled. Thus it is only an issue on hardware that does
support PCC. In that case, it is up to the remote controller to sanitize
communication; MCTP will be exposed as a socket interface, and userland
can send any crafted packet it wants. It would also be incumbent on
the hardware manufacturer to allow the end user to disable MCTP over PCC
communication if they did not want to expose it.
Signed-off-by: Adam Young <admiyo@os.amperecomputing.com>
---
Previous Version: https://lore.kernel.org/lkml/20260402212314.1364249-1-admiyo@os.amperecomputing.com/
Changes in V38:
- Release all struct sk_buff messages in Mailbox ring buffer when Network device is stopped
Changes in V37:
- Free Channel in error case during init MTU.
- Ensure Shared Buffer is > min-MTU + PCC Header
Changes in V36:
- added the CONFIG_PCC dependency
- altered the RX min length check to include at least the command and a MCTP header
- added a RX max-length check
- added a minimum MTU check
- altered the commit message to reflect PCC mailbox free behaviour.
Changes in V35:
- Removed spurious lines from commit
- Added context to commit message that was only in cover pages
Changes in V34:
- when checking size of the rx message, make sure it is not negative
- add size of the PCC header to skb bytes
Changes in V33:
- Removed Helper functions in mailbox/pcc.c.
- Used static helper function for writing to buffer
- Inlined code to read from buffer
- Corrected Copyright date
- Moved networks stats to the end of prepare_tx
- pull PCC header in MCTP sk_buff on error so not duplicated
Changed in V32:
- removed unused outbox variable in mctp_pcc_tx_done
- formatted mailbox/pcc.c kernel-docs IAW script
Changed in V31:
- Use predefined Header structure for pcc Extended buffers
- Rebased on top of changes for PCC to handle ACK interrupt and tx_complete
- Fixed formatting in mctp_pcc
- use netdev specific log function
- removed condition around dev_consume_skb_any(skb);
- initialized ndev->hard_header_len with sizeof PCC header
- removed spurious mctp_pcc_ndev = netdev_priv(ndev);
- Rebased on 6.19
Changed in V30:
- rebased on revert of mailbox/pcc.c code
- Explicit patch for dealing with PCC Type 3 ACK Interrupts
- PCC buffer management moved to helper functions
- PCC helper functions are explicitly called from Network Driver
- Removal of sk_buff queues
-
Changed in V29:
- Added a callback function for the mailbox API to allocate the rx_buffer
- The PCC mailbox to uses the Mailbox API callback instead of the PCC specific one
- The MCTP-PCC driver uses the Mailbox API callback instead of the PCC specific one
- Code review fixes for language in comments
- Removed PCC specific callback
Changes in V28:
- ndo open and ndo start create and free channels
- Max MTU is set in create
- Reverse XMass tree rules complied with
- Driver no longer has any auto-cleanup on registration functions
- Tested with KASAN
Changes in V27:
- Stop and restart packet Queues to deal with a full ring buffer
- drop the 'i' from the middle of the link name
- restore the allocation and freeing of the channel to the driver add/remove functions
leaving only the queue draining in the ndo stop function
Changes in V26:
- Remove the addition net-device spinlock and use the spinlock already present in skb lists
- Use temporary variables to check for success finding the skb in the lists
- Remove comment that is no longer relevant
Changes in V25:
- Use spin lock to control access to queues of sk_buffs
- removed unused constants
- added ndo_open and ndo_stop functions. These two functions do
channel creation and cleanup, to remove packets from the mailbox.
They do queue cleanup as well.
- No longer cleans up the channel from the device.
Changes in V24:
- Removed endianess for PCC header values
- Kept Column width to under 80 chars
- Typo in commit message
- Prereqisite patch for PCC buffer management was merged late in 6.17.
See "mailbox/pcc: support mailbox management of the shared buffer"
Changes in V23:
- Trigger for direct management of shared buffer based on flag in pcc channel
- Only initialize rx_alloc for inbox, not outbox.
- Read value for requested IRQ flag out of channel's current_req
- unqueue an sk_buff that failed to send
- Move error handling for skb resize error inline instead of goto
Changes in V22:
- Direct management of the shared buffer in the mailbox layer.
- Proper checking of command complete flag prior to writing to the buffer.
Changes in V21:
- Use existing constants PCC_SIGNATURE and PCC_CMD_COMPLETION_NOTIFY
- Check return code on call to send_data and drop packet if failed
- use sizeof(*mctp_pcc_header) etc, instead of structs for resizing buffers
- simplify check for ares->type != PCC_DWORD_TYPE
- simply return result devm_add_action_or_reset
- reduce initializer for mctp_pcc_lookup_context context = {};
- move initialization of mbox dev into mctp_pcc_initialize_mailbox
- minor spacing changes
Changes in V20:
- corrected typo in RFC version
- removed spurious space
- tx spin lock only controls access to shared memory buffer
- tx spin lock not eheld on error condition
- tx returns OK if skb can't be expanded
Changes in V19:
- Rebased on changes to PCC mailbox handling
- checks for cloned SKB prior to transmission
- converted doulbe slash comments to C comments
Changes in V18:
- Added Acked-By
- Fix minor spacing issue
Changes in V17:
- No new changes. Rebased on net-next post 6.13 release.
Changes in V16:
- do not duplicate cleanup after devm_add_action_or_reset calls
Changes in V15:
- corrected indentation formatting error
- Corrected TABS issue in MAINTAINER entry
Changes in V14:
- Do not attempt to unregister a netdev that is never registered
- Added MAINTAINER entry
Changes in V13:
- Explicitly Convert PCC header from little endian to machine native
Changes in V12:
- Explicitly use little endian conversion for PCC header signature
- Builds clean with make C=1
Changes in V11:
- Explicitly use little endian types for PCC header
Changes in V10:
- sync with net-next branch
- use dstats helper functions
- remove duplicate drop stat
- remove more double spaces
Changes in V9:
- Prerequisite patch for PCC mailbox has been merged
- Stats collection now use helper functions
- many double spaces reduced to single
Changes in V8:
- change 0 to NULL for pointer check of shmem
- add semi for static version of pcc_mbox_ioremap
- convert pcc_mbox_ioremap function to static inline when client code is not being built
- remove shmem comment from struct pcc_chan_info descriptor
- copy rx_dropped in mctp_pcc_net_stats
- removed trailing newline on error message
- removed double space in dev_dbg string
- use big endian for header members
- Fix use full spec ID in description
- Fix typo in file description
- Form the complete outbound message in the sk_buff
Changes in V7:
- Removed the Hardware address as specification is not published.
- Map the shared buffer in the mailbox and share the mapped region with the driver
- Use the sk_buff memory to prepare the message before copying to shared region
Changes in V6:
- Removed patch for ACPICA code that has merged
- Includes the hardware address in the network device
- Converted all device resources to devm resources
- Removed mctp_pcc_driver_remove function
- uses acpi_driver_module for initialization
- created helper structure for in and out mailboxes
- Consolidated code for initializing mailboxes in the add_device function
- Added specification references
- Removed duplicate constant PCC_ACK_FLAG_MASK
- Use the MCTP_SIGNATURE_LENGTH define
- made naming of header structs consistent
- use sizeof local variables for offset calculations
- prefix structure name to avoid potential clash
- removed unnecessary null initialization from acpi_device_id
Changes in V5
- Removed Owner field from ACPI module declaration
- removed unused next field from struct mctp_pcc_ndev
- Corrected logic reading RX ACK flag.
- Added comment for struct pcc_chan_info field shmem_base_addr
- check against current mtu instead of max mtu for packet length\
- removed unnecessary lookups of pnd->mdev.dev
Changes in V4
- Read flags out of shared buffer to trigger ACK for Type 4 RX
- Remove list of netdevs and cleanup from devices only
- tag PCCT protocol headers as little endian
- Remove unused constants
Changes in V3
- removed unused header
- removed spurious space
- removed spurious semis after functiomns
- removed null assignment for init
- remove redundant set of device on skb
- tabify constant declarations
- added rtnl_link_stats64 function
- set MTU to minimum to start
- clean up logic on driver removal
- remove cast on void * assignment
- call cleanup function directly
- check received length before allocating skb
- introduce symbolic constatn for ACK FLAG MASK
- symbolic constant for PCC header flag.
- Add namespace ID to PCC magic
- replaced readls with copy from io of PCC header
- replaced custom modules init and cleanup with ACPI version
Changes in V2
- All Variable Declarations are in reverse Xmass Tree Format
- All Checkpatch Warnings Are Fixed
- Removed Dead code
- Added packet tx/rx stats
- Removed network physical address. This is still in
disucssion in the spec, and will be added once there
is consensus. The protocol can be used with out it.
This also lead to the removal of the Big Endian
conversions.
- Avoided using non volatile pointers in copy to and from io space
- Reorderd the patches to put the ACK check for the PCC Mailbox
as a pre-requisite. The corresponding change for the MCTP
driver has been inlined in the main patch.
- Replaced magic numbers with constants, fixed typos, and other
minor changes from code review.
---
MAINTAINERS | 5 +
drivers/net/mctp/Kconfig | 14 ++
drivers/net/mctp/Makefile | 1 +
drivers/net/mctp/mctp-pcc.c | 367 ++++++++++++++++++++++++++++++++++++
4 files changed, 387 insertions(+)
create mode 100644 drivers/net/mctp/mctp-pcc.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 7a2ffd9d37d5..1813a2126cc0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -15288,6 +15288,11 @@ F: include/net/mctpdevice.h
F: include/net/netns/mctp.h
F: net/mctp/
+MANAGEMENT COMPONENT TRANSPORT PROTOCOL (MCTP) over PCC (MCTP-PCC) Driver
+M: Adam Young <admiyo@os.amperecomputing.com>
+S: Maintained
+F: drivers/net/mctp/mctp-pcc.c
+
MAPLE TREE
M: Liam R. Howlett <Liam.Howlett@oracle.com>
R: Alice Ryhl <aliceryhl@google.com>
diff --git a/drivers/net/mctp/Kconfig b/drivers/net/mctp/Kconfig
index cf325ab0b1ef..4503152c70bc 100644
--- a/drivers/net/mctp/Kconfig
+++ b/drivers/net/mctp/Kconfig
@@ -47,6 +47,20 @@ config MCTP_TRANSPORT_I3C
A MCTP protocol network device is created for each I3C bus
having a "mctp-controller" devicetree property.
+config MCTP_TRANSPORT_PCC
+ tristate "MCTP PCC transport"
+ depends on ACPI
+ depends on PCC
+ help
+ Provides a driver to access MCTP devices over PCC transport,
+ A MCTP protocol network device is created via ACPI for each
+ entry in the DSDT/SSDT that matches the identifier. The Platform
+ communication channels are selected from the corresponding
+ entries in the PCCT.
+
+ Say y here if you need to connect to MCTP endpoints over PCC. To
+ compile as a module, use m; the module will be called mctp-pcc.
+
config MCTP_TRANSPORT_USB
tristate "MCTP USB transport"
depends on USB
diff --git a/drivers/net/mctp/Makefile b/drivers/net/mctp/Makefile
index c36006849a1e..0a591299ffa9 100644
--- a/drivers/net/mctp/Makefile
+++ b/drivers/net/mctp/Makefile
@@ -1,4 +1,5 @@
obj-$(CONFIG_MCTP_SERIAL) += mctp-serial.o
obj-$(CONFIG_MCTP_TRANSPORT_I2C) += mctp-i2c.o
obj-$(CONFIG_MCTP_TRANSPORT_I3C) += mctp-i3c.o
+obj-$(CONFIG_MCTP_TRANSPORT_PCC) += mctp-pcc.o
obj-$(CONFIG_MCTP_TRANSPORT_USB) += mctp-usb.o
diff --git a/drivers/net/mctp/mctp-pcc.c b/drivers/net/mctp/mctp-pcc.c
new file mode 100644
index 000000000000..e62f572d066c
--- /dev/null
+++ b/drivers/net/mctp/mctp-pcc.c
@@ -0,0 +1,367 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * mctp-pcc.c - Driver for MCTP over PCC.
+ * Copyright (c) 2024-2026, Ampere Computing LLC
+ *
+ */
+
+/* Implementation of MCTP over PCC DMTF Specification DSP0256
+ * https://www.dmtf.org/sites/default/files/standards/documents/DSP0292_1.0.0WIP50.pdf
+ */
+
+#include <linux/acpi.h>
+#include <linux/hrtimer.h>
+#include <linux/if_arp.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/mailbox_client.h>
+#include <linux/module.h>
+#include <linux/netdevice.h>
+#include <linux/platform_device.h>
+#include <linux/skbuff.h>
+#include <linux/string.h>
+
+#include <acpi/acpi_bus.h>
+#include <acpi/acpi_drivers.h>
+#include <acpi/acrestyp.h>
+#include <acpi/actbl.h>
+#include <acpi/pcc.h>
+#include <net/mctp.h>
+#include <net/mctpdevice.h>
+
+#define MCTP_SIGNATURE "MCTP"
+#define MCTP_SIGNATURE_LENGTH (sizeof(MCTP_SIGNATURE) - 1)
+#define MCTP_MIN_MTU 68
+#define PCC_DWORD_TYPE 0x0c
+
+struct mctp_pcc_mailbox {
+ u32 index;
+ struct pcc_mbox_chan *chan;
+ struct mbox_client client;
+};
+
+/* The netdev structure. One of these per PCC adapter. */
+struct mctp_pcc_ndev {
+ struct net_device *ndev;
+ struct acpi_device *acpi_device;
+ struct mctp_pcc_mailbox inbox;
+ struct mctp_pcc_mailbox outbox;
+};
+
+static void mctp_pcc_client_rx_callback(struct mbox_client *cl, void *mssg)
+{
+ struct acpi_pcct_ext_pcc_shared_memory pcc_header;
+ struct mctp_pcc_ndev *mctp_pcc_ndev;
+ struct mctp_pcc_mailbox *inbox;
+ struct mctp_skb_cb *cb;
+ struct sk_buff *skb;
+ int size;
+
+ mctp_pcc_ndev = container_of(cl, struct mctp_pcc_ndev, inbox.client);
+ inbox = &mctp_pcc_ndev->inbox;
+ memcpy_fromio(&pcc_header, inbox->chan->shmem, sizeof(pcc_header));
+
+ // The message must at least have the PCC command indicating it is an MCTP
+ // message followed by the MCTP header, or we have a malformed message.
+ if (pcc_header.length < sizeof(pcc_header.command) + sizeof(struct mctp_hdr)) {
+ dev_dstats_rx_dropped(mctp_pcc_ndev->ndev);
+ return;
+ }
+
+ size = pcc_header.length - sizeof(pcc_header.command) + sizeof(pcc_header);
+ // If the reported size is larger than the shared memory, something is wrong
+ // and the best we can do is treat it as corrupted data.
+ if (size > inbox->chan->shmem_size) {
+ dev_dstats_rx_dropped(mctp_pcc_ndev->ndev);
+ return;
+ }
+
+ if (memcmp(&pcc_header.command, MCTP_SIGNATURE, MCTP_SIGNATURE_LENGTH) != 0) {
+ dev_dstats_rx_dropped(mctp_pcc_ndev->ndev);
+ return;
+ }
+
+ skb = netdev_alloc_skb(mctp_pcc_ndev->ndev, size);
+ if (!skb) {
+ dev_dstats_rx_dropped(mctp_pcc_ndev->ndev);
+ return;
+ }
+ skb_put(skb, size);
+ skb->protocol = htons(ETH_P_MCTP);
+ memcpy_fromio(skb->data, inbox->chan->shmem, size);
+ dev_dstats_rx_add(mctp_pcc_ndev->ndev, size);
+ skb_pull(skb, sizeof(pcc_header));
+ skb_reset_mac_header(skb);
+ skb_reset_network_header(skb);
+ cb = __mctp_cb(skb);
+ cb->halen = 0;
+ netif_rx(skb);
+}
+
+static netdev_tx_t mctp_pcc_tx(struct sk_buff *skb, struct net_device *ndev)
+{
+ struct acpi_pcct_ext_pcc_shared_memory *pcc_header;
+ struct mctp_pcc_ndev *mpnd = netdev_priv(ndev);
+ int len = skb->len;
+ int rc;
+
+ rc = skb_cow_head(skb, sizeof(*pcc_header));
+ if (rc) {
+ dev_dstats_tx_dropped(ndev);
+ kfree_skb(skb);
+ return NETDEV_TX_OK;
+ }
+
+ pcc_header = skb_push(skb, sizeof(*pcc_header));
+ pcc_header->signature = PCC_SIGNATURE | mpnd->outbox.index;
+ pcc_header->flags = PCC_CMD_COMPLETION_NOTIFY;
+ memcpy(&pcc_header->command, MCTP_SIGNATURE, MCTP_SIGNATURE_LENGTH);
+ pcc_header->length = len + MCTP_SIGNATURE_LENGTH;
+
+ rc = mbox_send_message(mpnd->outbox.chan->mchan, skb);
+ if (rc < 0) {
+ //Remove the header in case it gets sent again
+ skb_pull(skb, sizeof(*pcc_header));
+ netif_stop_queue(ndev);
+ return NETDEV_TX_BUSY;
+ }
+
+ return NETDEV_TX_OK;
+}
+
+static void mctp_pcc_tx_prepare(struct mbox_client *cl, void *mssg)
+{
+ struct mctp_pcc_ndev *mctp_pcc_ndev;
+ struct mctp_pcc_mailbox *outbox;
+ struct sk_buff *skb = mssg;
+
+ mctp_pcc_ndev = container_of(cl, struct mctp_pcc_ndev, outbox.client);
+ outbox = &mctp_pcc_ndev->outbox;
+
+ if (!skb)
+ return;
+
+ if (skb->len > outbox->chan->shmem_size) {
+ dev_dstats_tx_dropped(mctp_pcc_ndev->ndev);
+ return;
+ }
+ memcpy_toio(outbox->chan->shmem, skb->data, skb->len);
+}
+
+static void mctp_pcc_tx_done(struct mbox_client *c, void *mssg, int r)
+{
+ struct mctp_pcc_ndev *mctp_pcc_ndev;
+ struct sk_buff *skb = mssg;
+
+ mctp_pcc_ndev = container_of(c, struct mctp_pcc_ndev, outbox.client);
+ dev_dstats_tx_add(mctp_pcc_ndev->ndev, skb->len);
+ dev_consume_skb_any(skb);
+ netif_wake_queue(mctp_pcc_ndev->ndev);
+}
+
+static int mctp_pcc_ndo_open(struct net_device *ndev)
+{
+ struct mctp_pcc_ndev *mctp_pcc_ndev = netdev_priv(ndev);
+ struct mctp_pcc_mailbox *outbox, *inbox;
+
+ outbox = &mctp_pcc_ndev->outbox;
+ inbox = &mctp_pcc_ndev->inbox;
+
+ outbox->chan = pcc_mbox_request_channel(&outbox->client, outbox->index);
+ if (IS_ERR(outbox->chan))
+ return PTR_ERR(outbox->chan);
+
+ inbox->client.rx_callback = mctp_pcc_client_rx_callback;
+ inbox->chan = pcc_mbox_request_channel(&inbox->client, inbox->index);
+ if (IS_ERR(inbox->chan)) {
+ pcc_mbox_free_channel(outbox->chan);
+ return PTR_ERR(inbox->chan);
+ }
+ return 0;
+}
+
+static int mctp_pcc_ndo_stop(struct net_device *ndev)
+{
+ struct mctp_pcc_ndev *mctp_pcc_ndev;
+ unsigned int count, idx;
+ struct mbox_chan *chan;
+ struct sk_buff *skb;
+
+ mctp_pcc_ndev = netdev_priv(ndev);
+ chan = mctp_pcc_ndev->outbox.chan->mchan;
+
+ scoped_guard(spinlock_irqsave, &chan->lock) {
+ chan->active_req = NULL;
+ while (chan->msg_count > 0) {
+ count = chan->msg_count;
+ idx = chan->msg_free;
+ if (idx >= count)
+ idx -= count;
+ else
+ idx += MBOX_TX_QUEUE_LEN - count;
+ skb = chan->msg_data[idx];
+ dev_dstats_tx_dropped(ndev);
+ dev_consume_skb_any(skb);
+ chan->msg_count--;
+ chan->msg_free++;
+ }
+ }
+
+ pcc_mbox_free_channel(mctp_pcc_ndev->outbox.chan);
+ pcc_mbox_free_channel(mctp_pcc_ndev->inbox.chan);
+ return 0;
+}
+
+static const struct net_device_ops mctp_pcc_netdev_ops = {
+ .ndo_open = mctp_pcc_ndo_open,
+ .ndo_stop = mctp_pcc_ndo_stop,
+ .ndo_start_xmit = mctp_pcc_tx,
+};
+
+static void mctp_pcc_setup(struct net_device *ndev)
+{
+ ndev->type = ARPHRD_MCTP;
+ ndev->hard_header_len = sizeof(struct acpi_pcct_ext_pcc_shared_memory);
+ ndev->tx_queue_len = 0;
+ ndev->flags = IFF_NOARP;
+ ndev->netdev_ops = &mctp_pcc_netdev_ops;
+ ndev->needs_free_netdev = true;
+ ndev->pcpu_stat_type = NETDEV_PCPU_STAT_DSTATS;
+}
+
+struct mctp_pcc_lookup_context {
+ int index;
+ u32 inbox_index;
+ u32 outbox_index;
+};
+
+static acpi_status lookup_pcct_indices(struct acpi_resource *ares,
+ void *context)
+{
+ struct mctp_pcc_lookup_context *luc = context;
+ struct acpi_resource_address32 *addr;
+
+ if (ares->type != PCC_DWORD_TYPE)
+ return AE_OK;
+
+ addr = ACPI_CAST_PTR(struct acpi_resource_address32, &ares->data);
+ switch (luc->index) {
+ case 0:
+ luc->outbox_index = addr[0].address.minimum;
+ break;
+ case 1:
+ luc->inbox_index = addr[0].address.minimum;
+ break;
+ }
+ luc->index++;
+ return AE_OK;
+}
+
+static void mctp_cleanup_netdev(void *data)
+{
+ struct net_device *ndev = data;
+
+ mctp_unregister_netdev(ndev);
+}
+
+static int initialize_MTU(struct net_device *ndev)
+{
+ struct mctp_pcc_ndev *mctp_pcc_ndev;
+ struct mctp_pcc_mailbox *outbox;
+ struct pcc_mbox_chan *pchan;
+ int mctp_pcc_max_mtu;
+
+ mctp_pcc_ndev = netdev_priv(ndev);
+ outbox = &mctp_pcc_ndev->outbox;
+ pchan = pcc_mbox_request_channel(&outbox->client, outbox->index);
+ if (IS_ERR(pchan))
+ return -1;
+ if (pchan->shmem_size < MCTP_MIN_MTU + sizeof(struct acpi_pcct_ext_pcc_shared_memory)) {
+ pcc_mbox_free_channel(pchan);
+ return -1;
+ }
+ mctp_pcc_max_mtu = pchan->shmem_size - sizeof(struct acpi_pcct_ext_pcc_shared_memory);
+ pcc_mbox_free_channel(pchan);
+
+ ndev->mtu = MCTP_MIN_MTU;
+ ndev->max_mtu = mctp_pcc_max_mtu;
+ ndev->min_mtu = MCTP_MIN_MTU;
+
+ return 0;
+}
+
+static int mctp_pcc_driver_add(struct acpi_device *acpi_dev)
+{
+ struct mctp_pcc_lookup_context context = {0};
+ struct mctp_pcc_ndev *mctp_pcc_ndev;
+ struct device *dev = &acpi_dev->dev;
+ struct net_device *ndev;
+ acpi_handle dev_handle;
+ acpi_status status;
+ char name[32];
+ int rc;
+
+ dev_dbg(dev, "Adding mctp_pcc device for HID %s\n",
+ acpi_device_hid(acpi_dev));
+ dev_handle = acpi_device_handle(acpi_dev);
+ status = acpi_walk_resources(dev_handle, "_CRS", lookup_pcct_indices,
+ &context);
+ if (!ACPI_SUCCESS(status)) {
+ dev_err(dev, "FAILED to lookup PCC indexes from CRS\n");
+ return -EINVAL;
+ }
+
+ snprintf(name, sizeof(name), "mctppcc%d", context.inbox_index);
+ ndev = alloc_netdev(sizeof(*mctp_pcc_ndev), name, NET_NAME_PREDICTABLE,
+ mctp_pcc_setup);
+ if (!ndev)
+ return -ENOMEM;
+
+ mctp_pcc_ndev = netdev_priv(ndev);
+
+ mctp_pcc_ndev->inbox.index = context.inbox_index;
+ mctp_pcc_ndev->inbox.client.dev = dev;
+ mctp_pcc_ndev->outbox.index = context.outbox_index;
+ mctp_pcc_ndev->outbox.client.dev = dev;
+
+ mctp_pcc_ndev->outbox.client.tx_prepare = mctp_pcc_tx_prepare;
+ mctp_pcc_ndev->outbox.client.tx_done = mctp_pcc_tx_done;
+ mctp_pcc_ndev->acpi_device = acpi_dev;
+ mctp_pcc_ndev->ndev = ndev;
+ acpi_dev->driver_data = mctp_pcc_ndev;
+
+ rc = initialize_MTU(ndev);
+ if (rc)
+ goto free_netdev;
+
+ rc = mctp_register_netdev(ndev, NULL, MCTP_PHYS_BINDING_PCC);
+ if (rc)
+ goto free_netdev;
+
+ return devm_add_action_or_reset(dev, mctp_cleanup_netdev, ndev);
+free_netdev:
+ free_netdev(ndev);
+ return rc;
+}
+
+static const struct acpi_device_id mctp_pcc_device_ids[] = {
+ { "DMT0001" },
+ {}
+};
+
+static struct acpi_driver mctp_pcc_driver = {
+ .name = "mctp_pcc",
+ .class = "Unknown",
+ .ids = mctp_pcc_device_ids,
+ .ops = {
+ .add = mctp_pcc_driver_add,
+ },
+};
+
+module_acpi_driver(mctp_pcc_driver);
+
+MODULE_DEVICE_TABLE(acpi, mctp_pcc_device_ids);
+
+MODULE_DESCRIPTION("MCTP PCC ACPI device");
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Adam Young <admiyo@os.amperecomputing.com>");
--
2.43.0
^ permalink raw reply related
* Re: [Intel-wired-lan] [PATCH] ice: wait for reset completion in ice_resume()
From: Kohei Enju @ 2026-04-05 18:48 UTC (permalink / raw)
To: Aaron Ma
Cc: anthony.l.nguyen, przemyslaw.kitszel, andrew+netdev, davem,
edumazet, kuba, pabeni, intel-wired-lan, netdev, linux-kernel
In-Reply-To: <20260402024220.210466-1-aaron.ma@canonical.com>
On 04/02 10:42, Aaron Ma via Intel-wired-lan wrote:
> diff --git a/drivers/net/ethernet/intel/ice/ice_main.c b/drivers/net/ethernet/intel/ice/ice_main.c
> index 3c36e3641b9e9..a029c247510fd 100644
> --- a/drivers/net/ethernet/intel/ice/ice_main.c
> +++ b/drivers/net/ethernet/intel/ice/ice_main.c
> @@ -5702,6 +5702,16 @@ static int ice_resume(struct device *dev)
> /* Restart the service task */
> mod_timer(&pf->serv_tmr, round_jiffies(jiffies + pf->serv_tmr_period));
>
> + /* Wait for the scheduled reset to finish so that the device is fully
> + * operational before returning. Without this, userspace (e.g.
> + * NetworkManager) may try to open the net device while the
> + * asynchronous reset and rebuild is still in progress, resulting in
> + * "can't open net device while reset is in progress" errors.
> + */
nit:
IIUC, this change is best-effort, since ice_resume() still returns
success even if ice_wait_for_reset() fails. If so, the new comment may
be better phrased to reflect that.
Otherwise, it looks good to me.
^ permalink raw reply
* Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration
From: Carlo Szelinsky @ 2026-04-05 18:57 UTC (permalink / raw)
To: Andrew Lunn
Cc: Kory Maincent, Oleksij Rempel, Andrew Lunn, Heiner Kallweit,
Russell King, Jakub Kicinski, David S . Miller, Eric Dumazet,
Paolo Abeni, Simon Horman, netdev, linux-kernel, Carlo Szelinsky
In-Reply-To: <6185f9d8-dabe-4190-b020-711e3a046e64@lunn.ch>
Hi Andrew,
So I went and looked at whether we can just let EPROBE_DEFER do its
thing here, like you suggested.
From what I can tell, the issue is where it happens.
fwnode_mdiobus_register_phy() gets called during the MDIO bus scan in
__of_mdiobus_parse_phys(), and if any PHY returns -EPROBE_DEFER there,
the whole scan bails out - none of the PHYs on that bus get registered.
So you'd lose all networking on that bus just because one PHY's PSE
controller isn't ready yet.
I also dug into the timing question you raised. Correct me if I'm
wrong, but from what I see the deferred probe timeout is 10s and
regulator_late_cleanup fires at 30s, so the ordering would actually
work out - the consumer would get to claim the regulator before
cleanup kills it. It's more the bus level collateral damage that
seemed like the real problem to me.
That's basically why I ended up treating EPROBE_DEFER as non-fatal
for PSE during PHY registration and doing lazy resolution instead.
The admin_state_synced flag then covers the window between PSE
controller probe and whenever the lazy resolution actually happens.
But I might be looking at this the wrong way - would you rather we
defer the whole bus and accept that trade-off? Or does the lazy
approach seem reasonable for this case? Happy to hear if you have
a different idea entirely.
Cheers,
Carlo
^ permalink raw reply
* Re: [PATCH net 1/3] net/mlx5e: SD, Fix race condition in secondary device probe/remove
From: Shay Drori @ 2026-04-05 19:05 UTC (permalink / raw)
To: Jakub Kicinski
Cc: Tariq Toukan, Eric Dumazet, Paolo Abeni, Andrew Lunn,
David S. Miller, Saeed Mahameed, Mark Bloch, Leon Romanovsky,
Simon Horman, Kees Cook, Parav Pandit, Patrisious Haddad,
Gal Pressman, netdev, linux-rdma, linux-kernel
In-Reply-To: <20260402174531.33ff0ff6@kernel.org>
On 03/04/2026 3:45, Jakub Kicinski wrote:
> External email: Use caution opening links or attachments
>
>
> On Thu, 2 Apr 2026 23:03:10 +0300 Shay Drori wrote:
>> On 02/04/2026 6:08, Jakub Kicinski wrote:
>>> On Mon, 30 Mar 2026 22:34:10 +0300 Tariq Toukan wrote:
>>>> From: Shay Drory <shayd@nvidia.com>
>>>>
>>>> When utilizing Socket-Direct single netdev functionality the driver
>>>> resolves the actual auxiliary device using mlx5_sd_get_adev(). However,
>>>> the current implementation returns the primary ETH auxiliary device
>>>> without holding the device lock, leading to a potential race condition
>>>> where the ETH device could be unbound or removed concurrently during
>>>> probe, suspend, resume, or remove operations.[1]
>>>>
>>>> Fix this by introducing mlx5_sd_put_adev() and updating
>>>> mlx5_sd_get_adev() so that secondaries devices would acquire the device
>>>> lock of the returned auxiliary device. After the lock is acquired, a
>>>> second devcom check is needed[2].
>>>> In addition, update The callers to pair the get operation with the new
>>>> put operation, ensuring the lock is held while the auxiliary device is
>>>> being operated on and released afterwards.
>>>
>>> Please explain why the "primary" designation is reliable, and therefore
>>> we can be sure there will be no ABBA deadlock here
>>
>> The "primary" designation is determined once in sd_register(). It's set
>> before devcom is marked ready, and it never changes after that.
>> In Addition, The primary path never locks a secondary: When the primary
>> device invoke mlx5_sd_get_adev(), it sees dev == primary and returns.
>> no additional lock is taken.
>> Therefore lock ordering is always: secondary_lock → primary_lock. The
>> reverse never happens, so ABBA deadlock is impossible.
>
> And the device_lock instances have separate lockdep classes?
> So lockdep will also understand this?
I tested this patches with lockdep enable and didn't get a splat,
so it seems lockdep understand.
>
>> Does the above is the explanation you looked for?
>> If not, can you elaborate?
>> If yes, to add it to the commit message in V2?
>
> Sounds good, please add to the msg.
>
>>>> diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>>>> index b6c12460b54a..5761f655f488 100644
>>>> --- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>>>> +++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
>>>> @@ -6657,8 +6657,11 @@ static int mlx5e_resume(struct auxiliary_device *adev)
>>>> return err;
>>>>
>>>> actual_adev = mlx5_sd_get_adev(mdev, adev, edev->idx);
>>>> - if (actual_adev)
>>>> - return _mlx5e_resume(actual_adev);
>>>> + if (actual_adev) {
>>>> + err = _mlx5e_resume(actual_adev);
>>>> + mlx5_sd_put_adev(actual_adev, adev);
>>>> + return err;
>>>> + }
>>>> return 0;
>>>
>>> Feels like I recently complained about similar code y'all were trying
>>> to add. Magically and conditionally locking something in a get helper
>>> makes for extremely confusing code.
>>
>> Do you think explicit locking API is preferred here?
>> something like:
>> new_locking_api()
>>
>> mlx5_sd_get_adev()
>>
>> new_unlocking_api()
>
> Readability is hard, I'd just push the locking up into the callers TBH.
> Looks like there's only 4, the LoC delta isn't going to be huge.
I though about it, but AFAIU your suggestion, a race is still possible:
your suggestion is to lock the adev returned from mlx5_sd_get_adev().
but between mlx5_sd_get_adev() and the lock, the adev can be free...
Therefore, an SD helper is still needed.
do you have a preferred approach here?
thanks
^ permalink raw reply
* Re: [PATCH net 2/2] vsock/test: add MSG_PEEK after partial recv test
From: Arseniy Krasnov @ 2026-04-05 19:14 UTC (permalink / raw)
To: Luigi Leonardi, Stefan Hajnoczi, Stefano Garzarella,
Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <20260402-fix_peek-v1-2-ad274fcef77b@redhat.com>
02.04.2026 11:18, Luigi Leonardi wrote:
> Add a test that verifies MSG_PEEK works correctly after a partial
> recv().
>
> This is to test a bug that was present in the `virtio_transport_stream_do_peek()`
> when computing the number of bytes to copy: After a partial read, the
> peek function didn't take into consideration the number of bytes that
> were already read. So peeking the whole buffer would cause a out-of-bounds read,
> that resulted in a -EFAULT.
>
> This test does exactly this: do a partial recv on a buffer, then try to
> peek the whole buffer content.
>
> Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
> ---
> tools/testing/vsock/vsock_test.c | 64 ++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 64 insertions(+)
>
> diff --git a/tools/testing/vsock/vsock_test.c b/tools/testing/vsock/vsock_test.c
> index 5bd20ccd9335caafe68e8b7a5d02a4deb3d2deec..308f9f8f30d22bec5aaa282356e400d8438fe321 100644
> --- a/tools/testing/vsock/vsock_test.c
> +++ b/tools/testing/vsock/vsock_test.c
> @@ -346,6 +346,65 @@ static void test_stream_msg_peek_server(const struct test_opts *opts)
> return test_msg_peek_server(opts, false);
> }
>
> +#define PEEK_AFTER_RECV_LEN 100
Hi, may be we can just reuse MSG_PEEK_BUF_LEN which was already used in MSG_PEEK tests ?
Thanks
> +
> +static void test_stream_peek_after_recv_client(const struct test_opts *opts)
> +{
> + unsigned char buf[PEEK_AFTER_RECV_LEN];
> + int fd;
> + int i;
> +
> + fd = vsock_stream_connect(opts->peer_cid, opts->peer_port);
> + if (fd < 0) {
> + perror("connect");
> + exit(EXIT_FAILURE);
> + }
> +
> + for (i = 0; i < sizeof(buf); i++)
> + buf[i] = (unsigned char)i;
> +
> + control_expectln("SRVREADY");
> +
> + send_buf(fd, buf, sizeof(buf), 0, sizeof(buf));
> +
> + close(fd);
> +}
> +
> +static void test_stream_peek_after_recv_server(const struct test_opts *opts)
> +{
> + unsigned char buf[PEEK_AFTER_RECV_LEN];
> + int half = PEEK_AFTER_RECV_LEN / 2;
> + ssize_t ret;
> + int fd;
> +
> + fd = vsock_stream_accept(VMADDR_CID_ANY, opts->peer_port, NULL);
> + if (fd < 0) {
> + perror("accept");
> + exit(EXIT_FAILURE);
> + }
> +
> + control_writeln("SRVREADY");
> +
> + /* Partial recv to advance offset within the skb */
> + recv_buf(fd, buf, half, 0, half);
> +
> + /* Try to peek more than what remains: should return only 'half'
> + * bytes. Note: we can't use recv_buf() because it loops until
> + * all requested bytes are returned.
> + */
> + ret = recv(fd, buf, sizeof(buf), MSG_PEEK);
> + if (ret < 0) {
> + perror("recv");
> + exit(EXIT_FAILURE);
> + } else if (ret != half) {
> + fprintf(stderr, "MSG_PEEK after partial recv returned %d (expected %d)\n",
> + ret, half);
> + exit(EXIT_FAILURE);
> + }
> +
> + close(fd);
> +}
> +
> #define SOCK_BUF_SIZE (2 * 1024 * 1024)
> #define SOCK_BUF_SIZE_SMALL (64 * 1024)
> #define MAX_MSG_PAGES 4
> @@ -2520,6 +2579,11 @@ static struct test_case test_cases[] = {
> .run_client = test_stream_tx_credit_bounds_client,
> .run_server = test_stream_tx_credit_bounds_server,
> },
> + {
> + .name = "SOCK_STREAM MSG_PEEK after partial recv",
> + .run_client = test_stream_peek_after_recv_client,
> + .run_server = test_stream_peek_after_recv_server,
> + },
> {},
> };
>
>
^ permalink raw reply
* Re: [PATCH net 1/2] vsock/virtio: fix MSG_PEEK ignoring skb offset when calculating bytes to copy
From: Arseniy Krasnov @ 2026-04-05 19:22 UTC (permalink / raw)
To: Luigi Leonardi, Stefan Hajnoczi, Stefano Garzarella,
Michael S. Tsirkin, Jason Wang, Xuan Zhuo, Eugenio Pérez,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Simon Horman
Cc: kvm, virtualization, netdev, linux-kernel
In-Reply-To: <20260402-fix_peek-v1-1-ad274fcef77b@redhat.com>
02.04.2026 11:18, Luigi Leonardi wrote:
> `virtio_transport_stream_do_peek()` does not account for the skb offset
> when computing the number of bytes to copy.
>
> This means that, after a partial recv() that advances the offset, a peek
> requesting more bytes than are available in the sk_buff causes
> `skb_copy_datagram_iter()` to go past the valid payload, resulting in a -EFAULT.
>
> The dequeue path already handles this correctly.
> Apply the same logic to the peek path.
>
> Fixes: 0df7cd3c13e4 ("vsock/virtio/vhost: read data from non-linear skb")
> Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
> ---
> net/vmw_vsock/virtio_transport_common.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
> index 8a9fb23c6e853dfea0a24d3787f7d6eb351dd6c6..4b65bfe5d875111f115e0fc4c6727adb66f34830 100644
> --- a/net/vmw_vsock/virtio_transport_common.c
> +++ b/net/vmw_vsock/virtio_transport_common.c
> @@ -547,9 +547,8 @@ virtio_transport_stream_do_peek(struct vsock_sock *vsk,
> skb_queue_walk(&vvs->rx_queue, skb) {
> size_t bytes;
>
> - bytes = len - total;
> - if (bytes > skb->len)
> - bytes = skb->len;
> + bytes = min_t(size_t, len - total,
> + skb->len - VIRTIO_VSOCK_SKB_CB(skb)->offset);
>
> spin_unlock_bh(&vvs->rx_lock);
>
>
Acked-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
^ permalink raw reply
* Re: [PATCH 1/3] [v4, net-next] net: ethernet: ti-cpsw:: rename soft_reset() function
From: Arnd Bergmann @ 2026-04-05 19:31 UTC (permalink / raw)
To: Simon Horman
Cc: Ilias Apalodimas, Arnd Bergmann, Netdev, Andrew Lunn,
David S . Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Grygorii Strashko, Murali Karicheri, Siddharth Vadapalli,
Roger Quadros, Vladimir Oltean, Alexander Sverdlin, Ioana Ciornei,
Linux-OMAP, Kevin Hao, Daniel Zahka, linux-kernel
In-Reply-To: <20260404091100.GT113102@horms.kernel.org>
On Sat, Apr 4, 2026, at 11:11, Simon Horman wrote:
> On Thu, Apr 02, 2026 at 09:16:29PM +0200, Arnd Bergmann wrote:
>> On Thu, Apr 2, 2026, at 21:13, Ilias Apalodimas wrote:
>>
>> Before the c5013ac1dd0e1 commit, this was a 'static inline' function,
>> which is allowed to clash with other identifiers. Making it a global
>> symbol during the move was a problem.
>
>
> If we are going to treat this as a fix then probably it should be separated
> from the rest of the patchset and routed via net. With the rump patchset
> re-submitted to net-next once dependencies are in place.
I'll drop patch 1 then and send the other two when I get the next
regression with duplicate objects in a couple of releases. I'm
travelling at the moment and won't have time to rebase and test
before the merge window.
It's no longer urgent since both cpsw and dpaa2 have been broken for
years now since I first reported the regression.
Arnd
^ permalink raw reply
* [PATCH 1/1] selftests: vsock: avoid mktemp -u for Unix socket paths
From: CaoRuichuang @ 2026-04-05 19:57 UTC (permalink / raw)
To: Stefano Garzarella, Shuah Khan
Cc: virtualization, netdev, linux-kselftest, linux-kernel,
CaoRuichuang
The namespace tests create temporary Unix socket paths with mktemp -u and
then hand them to socat. That only prints an unused pathname and leaves
a race before the socket is created.
Create a private temporary directory with mktemp -d and place the Unix
socket inside it instead. This keeps the path unique without relying on
mktemp -u for filesystem socket names.
Signed-off-by: CaoRuichuang <create0818@163.com>
---
tools/testing/selftests/vsock/vmtest.sh | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/vsock/vmtest.sh b/tools/testing/selftests/vsock/vmtest.sh
index 86e338886..91e0037d2 100755
--- a/tools/testing/selftests/vsock/vmtest.sh
+++ b/tools/testing/selftests/vsock/vmtest.sh
@@ -718,6 +718,7 @@ test_ns_diff_global_host_connect_to_global_vm_ok() {
local pids pid pidfile
local ns0 ns1 port
declare -a pids
+ local unixdir
local unixfile
ns0="global0"
ns1="global1"
@@ -736,7 +737,8 @@ test_ns_diff_global_host_connect_to_global_vm_ok() {
oops_before=$(vm_dmesg_oops_count "${ns0}")
warn_before=$(vm_dmesg_warn_count "${ns0}")
- unixfile=$(mktemp -u /tmp/XXXX.sock)
+ unixdir=$(mktemp -d /tmp/vsock_vmtest_XXXXXX)
+ unixfile="${unixdir}/sock"
ip netns exec "${ns1}" \
socat TCP-LISTEN:"${TEST_HOST_PORT}",fork \
UNIX-CONNECT:"${unixfile}" &
@@ -758,6 +760,7 @@ test_ns_diff_global_host_connect_to_global_vm_ok() {
terminate_pids "${pids[@]}"
terminate_pidfiles "${pidfile}"
+ rm -rf "${unixdir}"
if [[ "${rc}" -ne 0 ]] || [[ "${dmesg_rc}" -ne 0 ]]; then
return "${KSFT_FAIL}"
@@ -814,6 +817,7 @@ test_ns_diff_global_vm_connect_to_global_host_ok() {
local ns0="global0"
local ns1="global1"
local port=12345
+ local unixdir
local unixfile
local dmesg_rc
local pidfile
@@ -826,7 +830,8 @@ test_ns_diff_global_vm_connect_to_global_host_ok() {
log_host "Setup socat bridge from ns ${ns0} to ns ${ns1} over port ${port}"
- unixfile=$(mktemp -u /tmp/XXXX.sock)
+ unixdir=$(mktemp -d /tmp/vsock_vmtest_XXXXXX)
+ unixfile="${unixdir}/sock"
ip netns exec "${ns0}" \
socat TCP-LISTEN:"${port}" UNIX-CONNECT:"${unixfile}" &
@@ -845,7 +850,7 @@ test_ns_diff_global_vm_connect_to_global_host_ok() {
if ! vm_start "${pidfile}" "${ns0}"; then
log_host "failed to start vm (cid=${cid}, ns=${ns0})"
terminate_pids "${pids[@]}"
- rm -f "${unixfile}"
+ rm -rf "${unixdir}"
return "${KSFT_FAIL}"
fi
@@ -862,7 +867,7 @@ test_ns_diff_global_vm_connect_to_global_host_ok() {
terminate_pidfiles "${pidfile}"
terminate_pids "${pids[@]}"
- rm -f "${unixfile}"
+ rm -rf "${unixdir}"
if [[ "${rc}" -ne 0 ]] || [[ "${dmesg_rc}" -ne 0 ]]; then
return "${KSFT_FAIL}"
--
2.39.5 (Apple Git-154)
^ permalink raw reply related
* [PATCH 1/1] selftests: vsock: avoid mktemp -u for Unix socket paths
From: CaoRuichuang @ 2026-04-05 19:57 UTC (permalink / raw)
To: Stefano Garzarella, Shuah Khan
Cc: virtualization, netdev, linux-kselftest, linux-kernel,
CaoRuichuang
The namespace tests create temporary Unix socket paths with mktemp -u and
then hand them to socat. That only prints an unused pathname and leaves
a race before the socket is created.
Create a private temporary directory with mktemp -d and place the Unix
socket inside it instead. This keeps the path unique without relying on
mktemp -u for filesystem socket names.
Signed-off-by: CaoRuichuang <create0818@163.com>
---
tools/testing/selftests/vsock/vmtest.sh | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/tools/testing/selftests/vsock/vmtest.sh b/tools/testing/selftests/vsock/vmtest.sh
index 86e338886..91e0037d2 100755
--- a/tools/testing/selftests/vsock/vmtest.sh
+++ b/tools/testing/selftests/vsock/vmtest.sh
@@ -718,6 +718,7 @@ test_ns_diff_global_host_connect_to_global_vm_ok() {
local pids pid pidfile
local ns0 ns1 port
declare -a pids
+ local unixdir
local unixfile
ns0="global0"
ns1="global1"
@@ -736,7 +737,8 @@ test_ns_diff_global_host_connect_to_global_vm_ok() {
oops_before=$(vm_dmesg_oops_count "${ns0}")
warn_before=$(vm_dmesg_warn_count "${ns0}")
- unixfile=$(mktemp -u /tmp/XXXX.sock)
+ unixdir=$(mktemp -d /tmp/vsock_vmtest_XXXXXX)
+ unixfile="${unixdir}/sock"
ip netns exec "${ns1}" \
socat TCP-LISTEN:"${TEST_HOST_PORT}",fork \
UNIX-CONNECT:"${unixfile}" &
@@ -758,6 +760,7 @@ test_ns_diff_global_host_connect_to_global_vm_ok() {
terminate_pids "${pids[@]}"
terminate_pidfiles "${pidfile}"
+ rm -rf "${unixdir}"
if [[ "${rc}" -ne 0 ]] || [[ "${dmesg_rc}" -ne 0 ]]; then
return "${KSFT_FAIL}"
@@ -814,6 +817,7 @@ test_ns_diff_global_vm_connect_to_global_host_ok() {
local ns0="global0"
local ns1="global1"
local port=12345
+ local unixdir
local unixfile
local dmesg_rc
local pidfile
@@ -826,7 +830,8 @@ test_ns_diff_global_vm_connect_to_global_host_ok() {
log_host "Setup socat bridge from ns ${ns0} to ns ${ns1} over port ${port}"
- unixfile=$(mktemp -u /tmp/XXXX.sock)
+ unixdir=$(mktemp -d /tmp/vsock_vmtest_XXXXXX)
+ unixfile="${unixdir}/sock"
ip netns exec "${ns0}" \
socat TCP-LISTEN:"${port}" UNIX-CONNECT:"${unixfile}" &
@@ -845,7 +850,7 @@ test_ns_diff_global_vm_connect_to_global_host_ok() {
if ! vm_start "${pidfile}" "${ns0}"; then
log_host "failed to start vm (cid=${cid}, ns=${ns0})"
terminate_pids "${pids[@]}"
- rm -f "${unixfile}"
+ rm -rf "${unixdir}"
return "${KSFT_FAIL}"
fi
@@ -862,7 +867,7 @@ test_ns_diff_global_vm_connect_to_global_host_ok() {
terminate_pidfiles "${pidfile}"
terminate_pids "${pids[@]}"
- rm -f "${unixfile}"
+ rm -rf "${unixdir}"
if [[ "${rc}" -ne 0 ]] || [[ "${dmesg_rc}" -ne 0 ]]; then
return "${KSFT_FAIL}"
--
2.39.5 (Apple Git-154)
^ permalink raw reply related
* Re: [net-next,PATCH v5 3/3] net: phy: realtek: Add property to enable SSC
From: Aleksander Jan Bajkowski @ 2026-04-05 20:23 UTC (permalink / raw)
To: Marek Vasut, netdev
Cc: David S. Miller, Andrew Lunn, Conor Dooley, Eric Dumazet,
Florian Fainelli, Heiner Kallweit, Ivan Galkin, Jakub Kicinski,
Krzysztof Kozlowski, Michael Klein, Paolo Abeni, Rob Herring,
Russell King, Vladimir Oltean, devicetree
In-Reply-To: <20260326210704.58912-3-marek.vasut@mailbox.org>
Hi Marek,
On 26/03/2026 22:06, Marek Vasut wrote:
> Add support for spread spectrum clocking (SSC) on RTL8211F(D)(I)-CG,
> RTL8211FS(I)(-VS)-CG, RTL8211FG(I)(-VS)-CG PHYs. The implementation
> follows EMI improvement application note Rev. 1.2 for these PHYs.
>
> The current implementation enables SSC for both RXC and SYSCLK clock
> signals. Introduce DT properties 'realtek,clkout-ssc-enable',
> 'realtek,rxc-ssc-enable' and 'realtek,sysclk-ssc-enable' which control
> CLKOUT, RXC and SYSCLK SSC spread spectrum clocking enablement on these
> signals.
>
> Signed-off-by: Marek Vasut <marek.vasut@mailbox.org>
> ---
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: Aleksander Jan Bajkowski <olek2@wp.pl>
> Cc: Andrew Lunn <andrew@lunn.ch>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: Florian Fainelli <f.fainelli@gmail.com>
> Cc: Heiner Kallweit <hkallweit1@gmail.com>
> Cc: Ivan Galkin <ivan.galkin@axis.com>
> Cc: Jakub Kicinski <kuba@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Michael Klein <michael@fossekall.de>
> Cc: Paolo Abeni <pabeni@redhat.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Russell King <linux@armlinux.org.uk>
> Cc: Vladimir Oltean <vladimir.oltean@nxp.com>
> Cc: devicetree@vger.kernel.org
> Cc: netdev@vger.kernel.org
> ---
> V2: Split SSC clock control for each CLKOUT, RXC, SYSCLK signal
> V3: Update RTL8211FVD PHYCR2 comment to state this PHY has PHYCR2 register,
> but SSC configuration is not supported due to different layout.
> V4: - Perform all SSC configuration before disabling CLKOUT
> - Perform all SSC configuration in the same order as in the SSC appnote
> - Rebase on current next, retest using spectrum analyzer again
> V5: s@SCC@SSC@ typo
> ---
> drivers/net/phy/realtek/realtek_main.c | 131 +++++++++++++++++++++++++
> 1 file changed, 131 insertions(+)
>
> diff --git a/drivers/net/phy/realtek/realtek_main.c b/drivers/net/phy/realtek/realtek_main.c
> index 023e47ad605bd..0b5d35841fdd4 100644
> --- a/drivers/net/phy/realtek/realtek_main.c
> +++ b/drivers/net/phy/realtek/realtek_main.c
> @@ -75,10 +75,18 @@
>
> #define RTL8211F_PHYCR2 0x19
> #define RTL8211F_CLKOUT_EN BIT(0)
> +#define RTL8211F_SYSCLK_SSC_EN BIT(3)
> #define RTL8211F_PHYCR2_PHY_EEE_ENABLE BIT(5)
> +#define RTL8211F_CLKOUT_SSC_EN BIT(7)
>
> #define RTL8211F_INSR 0x1d
>
> +/* RTL8211F SSC settings */
> +#define RTL8211F_SSC_PAGE 0xc44
> +#define RTL8211F_SSC_RXC 0x13
> +#define RTL8211F_SSC_SYSCLK 0x17
> +#define RTL8211F_SSC_CLKOUT 0x19
> +
> /* RTL8211F LED configuration */
> #define RTL8211F_LEDCR_PAGE 0xd04
> #define RTL8211F_LEDCR 0x10
> @@ -215,6 +223,9 @@ MODULE_LICENSE("GPL");
> struct rtl821x_priv {
> bool enable_aldps;
> bool disable_clk_out;
> + bool enable_clkout_ssc;
> + bool enable_rxc_ssc;
> + bool enable_sysclk_ssc;
> struct clk *clk;
> /* rtl8211f */
> u16 iner;
> @@ -278,6 +289,12 @@ static int rtl821x_probe(struct phy_device *phydev)
> "realtek,aldps-enable");
> priv->disable_clk_out = of_property_read_bool(dev->of_node,
> "realtek,clkout-disable");
> + priv->enable_clkout_ssc = of_property_read_bool(dev->of_node,
> + "realtek,clkout-ssc-enable");
> + priv->enable_rxc_ssc = of_property_read_bool(dev->of_node,
> + "realtek,rxc-ssc-enable");
> + priv->enable_sysclk_ssc = of_property_read_bool(dev->of_node,
> + "realtek,sysclk-ssc-enable");
>
> phydev->priv = priv;
>
> @@ -707,6 +724,108 @@ static int rtl8211f_config_phy_eee(struct phy_device *phydev)
> RTL8211F_PHYCR2_PHY_EEE_ENABLE, 0);
> }
>
> +static int rtl8211f_config_clkout_ssc(struct phy_device *phydev)
> +{
> + struct rtl821x_priv *priv = phydev->priv;
> + struct device *dev = &phydev->mdio.dev;
> + int ret;
> +
> + /* The value is preserved if the device tree property is absent */
> + if (!priv->enable_clkout_ssc)
> + return 0;
> +
> + /* RTL8211FVD has PHYCR2 register, but configuration of CLKOUT SSC
> + * is not currently supported by this driver due to different bit
> + * layout.
> + */
> + if (phydev->drv->phy_id == RTL_8211FVD_PHYID)
> + return 0;
> +
> + /* Unnamed registers from EMI improvement parameters application note 1.2 */
> + ret = phy_write_paged(phydev, 0xd09, 0x10, 0xcf00);
> + if (ret < 0) {
> + dev_err(dev, "CLKOUT SSC initialization failed: %pe\n", ERR_PTR(ret));
> + return ret;
> + }
> +
> + ret = phy_write(phydev, RTL8211F_SSC_CLKOUT, 0x38c3);
Only registers 0x10–0x17 require paged operations. The remaining registers
are mapped directly into the PHY address space. This is mentioned in commit
650e55f224a575cdb18c984b95036109519502d1. Paged and direct access return
the same results. With this in mind, I believe that RTL8211F_SSC_CLKOUT is
an alias for RTL8211F_PHYCR2 and is described on page 45 of the
datasheet[1].
1. RTL8211F(I)-CG/RTL8211FD(I)-CG Datasheet
Best Regards,
Aleksander
^ 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