* Re: [PATCH] mptcp: add per-reason MIB counters for MPTCP_RST_EMPTCP resets
From: Shardul Bankar @ 2026-04-21 10:24 UTC (permalink / raw)
To: Matthieu Baerts, martineau
Cc: geliang, davem, edumazet, kuba, pabeni, horms, netdev, mptcp,
linux-kernel, janak, kalpan.jani
In-Reply-To: <3dbda2d2-c7e5-4a12-90c0-d1f98e3d89ee@kernel.org>
On Tue, 2026-04-21 at 12:14 +0200, Matthieu Baerts wrote:
> Hi Shardul,
>
>
> Even if the patch looks globally good, net-next is currently closed,
> and
> only bug fixes are accepted, see:
>
> https://docs.kernel.org/process/maintainer-netdev.html
>
> pw-bot: defer
>
> Instead, I suggest switching the discussions only on the MPTCP ML: I
> will try to review this patch and only send a reply to you and the
> MPTCP
> list, if that's OK.
>
> Cheers,
> Matt
Hi Matt,
Thanks for looking at this. Happy to continue on the MPTCP list.
Thanks,
Shardul
^ permalink raw reply
* RE: [Intel-wired-lan] [PATCH net] iavf: iavf_virtchnl_completion: drop duplicate ether_addr_equal() test
From: Loktionov, Aleksandr @ 2026-04-21 10:20 UTC (permalink / raw)
To: Vinschen, Corinna, intel-wired-lan@osuosl.org,
netdev@vger.kernel.org
Cc: Vinschen, Corinna, Jose Ignacio Tornos Martinez
In-Reply-To: <20260421095947.868695-1-vinschen@redhat.com>
> -----Original Message-----
> From: Intel-wired-lan <intel-wired-lan-bounces@osuosl.org> On Behalf
> Of Corinna Vinschen
> Sent: Tuesday, April 21, 2026 12:00 PM
> To: intel-wired-lan@osuosl.org; netdev@vger.kernel.org
> Cc: Vinschen, Corinna <vinschen@redhat.com>; Jose Ignacio Tornos
> Martinez <jtornosm@redhat.com>
> Subject: [Intel-wired-lan] [PATCH net] iavf: iavf_virtchnl_completion:
> drop duplicate ether_addr_equal() test
>
> This is just a simple cleanup fix. Commit 35a2443d0910f ("iavf: Add
> waiting for response from PF in set mac") introduced a duplicate
> ether_addr_equal() check, so the current code tests the new MAC twice
> against the former MAC.
>
> Remove the outer ether_addr_equal() test, remnant of commit
> c5c922b3e09b
> ("iavf: fix MAC address setting for VFs when filter is rejected")
>
> Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
> Fixes: 35a2443d0910f ("iavf: Add waiting for response from PF in set
> mac")
I think Cc: stable@vger.kernel.org should be added.
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
> ---
> drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 12 +++++-------
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> index a52c100dcbc5..9b8e7e4376c2 100644
> --- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> +++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
> @@ -2579,13 +2579,11 @@ void iavf_virtchnl_completion(struct
> iavf_adapter *adapter,
> case VIRTCHNL_OP_ADD_ETH_ADDR:
> if (!v_retval)
> iavf_mac_add_ok(adapter);
> - if (!ether_addr_equal(netdev->dev_addr, adapter-
> >hw.mac.addr))
> - if (!ether_addr_equal(netdev->dev_addr,
> - adapter->hw.mac.addr)) {
> - netif_addr_lock_bh(netdev);
> - eth_hw_addr_set(netdev, adapter-
> >hw.mac.addr);
> - netif_addr_unlock_bh(netdev);
> - }
> + if (!ether_addr_equal(netdev->dev_addr, adapter-
> >hw.mac.addr)) {
> + netif_addr_lock_bh(netdev);
> + eth_hw_addr_set(netdev, adapter->hw.mac.addr);
> + netif_addr_unlock_bh(netdev);
> + }
> wake_up(&adapter->vc_waitqueue);
> break;
> case VIRTCHNL_OP_GET_STATS: {
> --
> 2.53.0
^ permalink raw reply
* Re: [PATCH] mptcp: add per-reason MIB counters for MPTCP_RST_EMPTCP resets
From: Matthieu Baerts @ 2026-04-21 10:14 UTC (permalink / raw)
To: Shardul Bankar, martineau
Cc: geliang, davem, edumazet, kuba, pabeni, horms, netdev, mptcp,
linux-kernel, janak, kalpan.jani, Shardul Bankar
In-Reply-To: <20260421095646.3741956-1-shardul.b@mpiricsoftware.com>
Hi Shardul,
On 21/04/2026 11:56, Shardul Bankar wrote:
> MPTCP_RST_EMPTCP (reset reason 1) is used as a catch-all for seven
> distinct error conditions across subflow setup, authentication, and
> data path validation. The existing MPRstTx/MPRstRx counters only
> track aggregate reset volume, making it difficult to diagnose which
> code path is triggering subflow resets in production.
>
> Add per-reason MIB counters for each MPTCP_RST_EMPTCP use site:
>
> MPRstMD5SIG - MD5SIG on listener, incompatible with MPTCP
> MPRstNoToken - JOIN token lookup failed, no matching conn
> MPRstNoMPJ - SYN/ACK missing MP_JOIN option
> MPRstHMAC - HMAC validation failed during subflow join
> MPRstFatalFallback - fatal fallback during child socket creation
> MPRstBadMap - invalid data mapping on established subflow
> MPRstNotEstablished - JOIN on not-fully-established msk
>
> These counters are incremented alongside the existing reset_reason
> assignment and are visible via nstat as MPTcpExtMPRst*. The
> aggregate MPRstTx/MPRstRx counters remain unchanged.
Thank you for this patch.
Even if the patch looks globally good, net-next is currently closed, and
only bug fixes are accepted, see:
https://docs.kernel.org/process/maintainer-netdev.html
pw-bot: defer
Instead, I suggest switching the discussions only on the MPTCP ML: I
will try to review this patch and only send a reply to you and the MPTCP
list, if that's OK.
Cheers,
Matt
--
Sponsored by the NGI0 Core fund.
^ permalink raw reply
* [PATCH net] iavf: iavf_virtchnl_completion: drop duplicate ether_addr_equal() test
From: Corinna Vinschen @ 2026-04-21 9:59 UTC (permalink / raw)
To: intel-wired-lan, netdev
Cc: Jose Ignacio Tornos Martinez, Michal Schmidt, Corinna Vinschen
This is just a simple cleanup fix. Commit 35a2443d0910f ("iavf: Add
waiting for response from PF in set mac") introduced a duplicate
ether_addr_equal() check, so the current code tests the new MAC twice
against the former MAC.
Remove the outer ether_addr_equal() test, remnant of commit c5c922b3e09b
("iavf: fix MAC address setting for VFs when filter is rejected")
Signed-off-by: Corinna Vinschen <vinschen@redhat.com>
Fixes: 35a2443d0910f ("iavf: Add waiting for response from PF in set mac")
---
drivers/net/ethernet/intel/iavf/iavf_virtchnl.c | 12 +++++-------
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
index a52c100dcbc5..9b8e7e4376c2 100644
--- a/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
+++ b/drivers/net/ethernet/intel/iavf/iavf_virtchnl.c
@@ -2579,13 +2579,11 @@ void iavf_virtchnl_completion(struct iavf_adapter *adapter,
case VIRTCHNL_OP_ADD_ETH_ADDR:
if (!v_retval)
iavf_mac_add_ok(adapter);
- if (!ether_addr_equal(netdev->dev_addr, adapter->hw.mac.addr))
- if (!ether_addr_equal(netdev->dev_addr,
- adapter->hw.mac.addr)) {
- netif_addr_lock_bh(netdev);
- eth_hw_addr_set(netdev, adapter->hw.mac.addr);
- netif_addr_unlock_bh(netdev);
- }
+ if (!ether_addr_equal(netdev->dev_addr, adapter->hw.mac.addr)) {
+ netif_addr_lock_bh(netdev);
+ eth_hw_addr_set(netdev, adapter->hw.mac.addr);
+ netif_addr_unlock_bh(netdev);
+ }
wake_up(&adapter->vc_waitqueue);
break;
case VIRTCHNL_OP_GET_STATS: {
--
2.53.0
^ permalink raw reply related
* [PATCH] mptcp: add per-reason MIB counters for MPTCP_RST_EMPTCP resets
From: Shardul Bankar @ 2026-04-21 9:56 UTC (permalink / raw)
To: matttbe, martineau
Cc: geliang, davem, edumazet, kuba, pabeni, horms, netdev, mptcp,
linux-kernel, janak, kalpan.jani, shardulsb08, Shardul Bankar
MPTCP_RST_EMPTCP (reset reason 1) is used as a catch-all for seven
distinct error conditions across subflow setup, authentication, and
data path validation. The existing MPRstTx/MPRstRx counters only
track aggregate reset volume, making it difficult to diagnose which
code path is triggering subflow resets in production.
Add per-reason MIB counters for each MPTCP_RST_EMPTCP use site:
MPRstMD5SIG - MD5SIG on listener, incompatible with MPTCP
MPRstNoToken - JOIN token lookup failed, no matching conn
MPRstNoMPJ - SYN/ACK missing MP_JOIN option
MPRstHMAC - HMAC validation failed during subflow join
MPRstFatalFallback - fatal fallback during child socket creation
MPRstBadMap - invalid data mapping on established subflow
MPRstNotEstablished - JOIN on not-fully-established msk
These counters are incremented alongside the existing reset_reason
assignment and are visible via nstat as MPTcpExtMPRst*. The
aggregate MPRstTx/MPRstRx counters remain unchanged.
Closes: https://github.com/multipath-tcp/mptcp_net-next/issues/511
Signed-off-by: Shardul Bankar <shardul.b@mpiricsoftware.com>
---
net/mptcp/mib.c | 7 +++++++
net/mptcp/mib.h | 7 +++++++
net/mptcp/protocol.c | 1 +
net/mptcp/subflow.c | 14 +++++++++++---
4 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/net/mptcp/mib.c b/net/mptcp/mib.c
index f23fda0c55a7..ec42583c59cf 100644
--- a/net/mptcp/mib.c
+++ b/net/mptcp/mib.c
@@ -71,6 +71,13 @@ static const struct snmp_mib mptcp_snmp_list[] = {
SNMP_MIB_ITEM("MPFastcloseRx", MPTCP_MIB_MPFASTCLOSERX),
SNMP_MIB_ITEM("MPRstTx", MPTCP_MIB_MPRSTTX),
SNMP_MIB_ITEM("MPRstRx", MPTCP_MIB_MPRSTRX),
+ SNMP_MIB_ITEM("MPRstMD5SIG", MPTCP_MIB_MPRSTMD5SIG),
+ SNMP_MIB_ITEM("MPRstNoToken", MPTCP_MIB_MPRSTNOTOKEN),
+ SNMP_MIB_ITEM("MPRstNoMPJ", MPTCP_MIB_MPRSTNOMPJ),
+ SNMP_MIB_ITEM("MPRstHMAC", MPTCP_MIB_MPRSTHMAC),
+ SNMP_MIB_ITEM("MPRstFatalFallback", MPTCP_MIB_MPRSTFATALFALLBACK),
+ SNMP_MIB_ITEM("MPRstBadMap", MPTCP_MIB_MPRSTBADMAP),
+ SNMP_MIB_ITEM("MPRstNotEstablished", MPTCP_MIB_MPRSTNOTESTABLISHED),
SNMP_MIB_ITEM("SubflowStale", MPTCP_MIB_SUBFLOWSTALE),
SNMP_MIB_ITEM("SubflowRecover", MPTCP_MIB_SUBFLOWRECOVER),
SNMP_MIB_ITEM("SndWndShared", MPTCP_MIB_SNDWNDSHARED),
diff --git a/net/mptcp/mib.h b/net/mptcp/mib.h
index 812218b5ed2b..0ac109b52d35 100644
--- a/net/mptcp/mib.h
+++ b/net/mptcp/mib.h
@@ -70,6 +70,13 @@ enum linux_mptcp_mib_field {
MPTCP_MIB_MPFASTCLOSERX, /* Received a MP_FASTCLOSE */
MPTCP_MIB_MPRSTTX, /* Transmit a MP_RST */
MPTCP_MIB_MPRSTRX, /* Received a MP_RST */
+ MPTCP_MIB_MPRSTMD5SIG, /* MP_RST: MD5SIG enabled on listener */
+ MPTCP_MIB_MPRSTNOTOKEN, /* MP_RST: JOIN token not found */
+ MPTCP_MIB_MPRSTNOMPJ, /* MP_RST: missing MPJ in SYN/ACK */
+ MPTCP_MIB_MPRSTHMAC, /* MP_RST: HMAC validation failed */
+ MPTCP_MIB_MPRSTFATALFALLBACK, /* MP_RST: fatal fallback on child */
+ MPTCP_MIB_MPRSTBADMAP, /* MP_RST: bad data mapping */
+ MPTCP_MIB_MPRSTNOTESTABLISHED, /* MP_RST: JOIN on not-established msk */
MPTCP_MIB_SUBFLOWSTALE, /* Subflows entered 'stale' status */
MPTCP_MIB_SUBFLOWRECOVER, /* Subflows returned to active status after being stale */
MPTCP_MIB_SNDWNDSHARED, /* Subflow snd wnd is overridden by msk's one */
diff --git a/net/mptcp/protocol.c b/net/mptcp/protocol.c
index 17b9a8c13ebf..b06cbcf983f4 100644
--- a/net/mptcp/protocol.c
+++ b/net/mptcp/protocol.c
@@ -3836,6 +3836,7 @@ bool mptcp_finish_join(struct sock *ssk)
/* mptcp socket already closing? */
if (!mptcp_is_fully_established(parent)) {
+ MPTCP_INC_STATS(sock_net(parent), MPTCP_MIB_MPRSTNOTESTABLISHED);
subflow->reset_reason = MPTCP_RST_EMPTCP;
return false;
}
diff --git a/net/mptcp/subflow.c b/net/mptcp/subflow.c
index e2cb9d23e4a0..71bffcda0138 100644
--- a/net/mptcp/subflow.c
+++ b/net/mptcp/subflow.c
@@ -160,6 +160,7 @@ static int subflow_check_req(struct request_sock *req,
* TCP option space.
*/
if (rcu_access_pointer(tcp_sk(sk_listener)->md5sig_info)) {
+ MPTCP_INC_STATS(sock_net(sk_listener), MPTCP_MIB_MPRSTMD5SIG);
subflow_add_reset_reason(skb, MPTCP_RST_EMPTCP);
return -EINVAL;
}
@@ -227,6 +228,7 @@ static int subflow_check_req(struct request_sock *req,
/* Can't fall back to TCP in this case. */
if (!subflow_req->msk) {
+ MPTCP_INC_STATS(sock_net(sk_listener), MPTCP_MIB_MPRSTNOTOKEN);
subflow_add_reset_reason(skb, MPTCP_RST_EMPTCP);
return -EPERM;
}
@@ -568,6 +570,7 @@ static void subflow_finish_connect(struct sock *sk, const struct sk_buff *skb)
u8 hmac[SHA256_DIGEST_SIZE];
if (!(mp_opt.suboptions & OPTION_MPTCP_MPJ_SYNACK)) {
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_MPRSTNOMPJ);
subflow->reset_reason = MPTCP_RST_EMPTCP;
goto do_reset;
}
@@ -582,6 +585,7 @@ static void subflow_finish_connect(struct sock *sk, const struct sk_buff *skb)
if (!subflow_thmac_valid(subflow)) {
MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_JOINACKMAC);
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_MPRSTHMAC);
subflow->reset_reason = MPTCP_RST_EMPTCP;
goto do_reset;
}
@@ -870,6 +874,7 @@ static struct sock *subflow_syn_recv_sock(const struct sock *sk,
*/
if (!ctx || fallback) {
if (fallback_is_fatal) {
+ MPTCP_INC_STATS(sock_net(sk), MPTCP_MIB_MPRSTFATALFALLBACK);
subflow_add_reset_reason(skb, MPTCP_RST_EMPTCP);
goto dispose_child;
}
@@ -1421,9 +1426,12 @@ static bool subflow_check_data_avail(struct sock *ssk)
* subflow_error_report() will introduce the appropriate barriers
*/
subflow->reset_transient = 0;
- subflow->reset_reason = status == MAPPING_NODSS ?
- MPTCP_RST_EMIDDLEBOX :
- MPTCP_RST_EMPTCP;
+ if (status == MAPPING_NODSS) {
+ subflow->reset_reason = MPTCP_RST_EMIDDLEBOX;
+ } else {
+ MPTCP_INC_STATS(sock_net(ssk), MPTCP_MIB_MPRSTBADMAP);
+ subflow->reset_reason = MPTCP_RST_EMPTCP;
+ }
reset:
WRITE_ONCE(ssk->sk_err, EBADMSG);
--
2.34.1
^ permalink raw reply related
* Re: [PATCH net v8 03/15] net: cache snapshot entries for ndo_set_rx_mode_async
From: Paolo Abeni @ 2026-04-21 9:52 UTC (permalink / raw)
To: Stanislav Fomichev, netdev; +Cc: davem, edumazet, kuba
In-Reply-To: <20260416185712.2155425-4-sdf@fomichev.me>
On 4/16/26 8:57 PM, Stanislav Fomichev wrote:
> Add a per-device netdev_hw_addr_list cache (rx_mode_addr_cache) that
> allows __hw_addr_list_snapshot() and __hw_addr_list_reconcile() to
> reuse previously allocated entries instead of hitting GFP_ATOMIC on
> every snapshot cycle.
>
> snapshot pops entries from the cache when available, falling back to
> __hw_addr_create(). reconcile splices both snapshot lists back into
> the cache via __hw_addr_splice(). The cache is flushed in
> free_netdev().
>
> Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
> (cherry picked from commit ba3ab1832a511f660fdc6231245b14bf610c05bd)
Are you backporting from 7.2 via time machine??? :-P
> @@ -611,8 +633,8 @@ void __hw_addr_list_reconcile(struct netdev_hw_addr_list *real_list,
> }
> }
>
> - __hw_addr_flush(work);
> - __hw_addr_flush(ref);
> + __hw_addr_splice(cache, work);
> + __hw_addr_splice(cache, ref);
I think here sashiko has a point, with the cache size being unbounded. I
guess syzkaller or the like will find a way to make it grow too much.
What about hard-limit it to some reasonable value?!?
/P
^ permalink raw reply
* [PATCH net] net: ipv6: fix NOREF dst use in seg6 and rpl lwtunnels
From: Andrea Mayer @ 2026-04-21 9:47 UTC (permalink / raw)
To: davem, dsahern, edumazet, kuba, pabeni, horms
Cc: bigeasy, clrkwllms, rostedt, david.lebrun, alex.aring,
stefano.salsano, andrea.mayer, netdev, linux-rt-devel,
linux-kernel, stable
seg6_input_core() and rpl_input() call ip6_route_input() which sets a
NOREF dst on the skb, then pass it to dst_cache_set_ip6() invoking
dst_hold() unconditionally.
On PREEMPT_RT, ksoftirqd is preemptible and a higher-priority task can
release the underlying pcpu_rt between the lookup and the caching
through a concurrent FIB lookup on a shared nexthop.
Simplified race sequence:
ksoftirqd/X higher-prio task (same CPU X)
----------- --------------------------------
seg6_input_core(,skb)/rpl_input(skb)
dst_cache_get()
-> miss
ip6_route_input(skb)
-> ip6_pol_route(,skb,flags)
[RT6_LOOKUP_F_DST_NOREF in flags]
-> FIB lookup resolves fib6_nh
[nhid=N route]
-> rt6_make_pcpu_route()
[creates pcpu_rt, refcount=1]
pcpu_rt->sernum = fib6_sernum
[fib6_sernum=W]
-> cmpxchg(fib6_nh.rt6i_pcpu,
NULL, pcpu_rt)
[slot was empty, store succeeds]
-> skb_dst_set_noref(skb, dst)
[dst is pcpu_rt, refcount still 1]
rt_genid_bump_ipv6()
-> bumps fib6_sernum
[fib6_sernum from W to Z]
ip6_route_output()
-> ip6_pol_route()
-> FIB lookup resolves fib6_nh
[nhid=N]
-> rt6_get_pcpu_route()
pcpu_rt->sernum != fib6_sernum
[W <> Z, stale]
-> prev = xchg(rt6i_pcpu, NULL)
-> dst_release(prev)
[prev is pcpu_rt,
refcount 1->0, dead]
dst = skb_dst(skb)
[dst is the dead pcpu_rt]
dst_cache_set_ip6(dst)
-> dst_hold() on dead dst
-> WARN / use-after-free
For the race to occur, ksoftirqd must be preemptible (PREEMPT_RT without
PREEMPT_RT_NEEDS_BH_LOCK) and a concurrent task must be able to release
the pcpu_rt. Shared nexthop objects provide such a path, as two routes
pointing to the same nhid share the same fib6_nh and its rt6i_pcpu
entry.
Fix seg6_input_core() and rpl_input() by calling skb_dst_force() after
ip6_route_input() to force the NOREF dst into a refcounted one before
caching.
The output path is not affected as ip6_route_output() already returns a
refcounted dst.
Fixes: af4a2209b134 ("ipv6: sr: use dst_cache in seg6_input")
Fixes: a7a29f9c361f ("net: ipv6: add rpl sr tunnel")
Cc: stable@vger.kernel.org
Signed-off-by: Andrea Mayer <andrea.mayer@uniroma2.it>
---
net/ipv6/rpl_iptunnel.c | 9 +++++++++
net/ipv6/seg6_iptunnel.c | 9 +++++++++
2 files changed, 18 insertions(+)
diff --git a/net/ipv6/rpl_iptunnel.c b/net/ipv6/rpl_iptunnel.c
index c7942cf65567..4e10adcd70e8 100644
--- a/net/ipv6/rpl_iptunnel.c
+++ b/net/ipv6/rpl_iptunnel.c
@@ -287,7 +287,16 @@ static int rpl_input(struct sk_buff *skb)
if (!dst) {
ip6_route_input(skb);
+
+ /* ip6_route_input() sets a NOREF dst; force a refcount on it
+ * before caching or further use.
+ */
+ skb_dst_force(skb);
dst = skb_dst(skb);
+ if (unlikely(!dst)) {
+ err = -ENETUNREACH;
+ goto drop;
+ }
/* cache only if we don't create a dst reference loop */
if (!dst->error && lwtst != dst->lwtstate) {
diff --git a/net/ipv6/seg6_iptunnel.c b/net/ipv6/seg6_iptunnel.c
index 97b50d9b1365..94284b483be0 100644
--- a/net/ipv6/seg6_iptunnel.c
+++ b/net/ipv6/seg6_iptunnel.c
@@ -515,7 +515,16 @@ static int seg6_input_core(struct net *net, struct sock *sk,
if (!dst) {
ip6_route_input(skb);
+
+ /* ip6_route_input() sets a NOREF dst; force a refcount on it
+ * before caching or further use.
+ */
+ skb_dst_force(skb);
dst = skb_dst(skb);
+ if (unlikely(!dst)) {
+ err = -ENETUNREACH;
+ goto drop;
+ }
/* cache only if we don't create a dst reference loop */
if (!dst->error && lwtst != dst->lwtstate) {
--
2.20.1
^ permalink raw reply related
* Re: [PATCH] ieee802154: ca8210: fix cas_ctl leak on spi_async failure
From: Markus Elfring @ 2026-04-21 9:47 UTC (permalink / raw)
To: Shitalkumar Gandhi, linux-wpan, netdev, Alexander Aring,
Miquel Raynal, Stefan Schmidt
Cc: Shitalkumar Gandhi, stable, LKML, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni
In-Reply-To: <20260421073259.2259783-1-shitalkumar.gandhi@cambiumnetworks.com>
…
> Fix it by freeing cas_ctl on the spi_async() error path. While here,
> correct the misleading error string: the function calls spi_async(),
> not spi_sync().
Would it be safer to offer desired changes as separate patches?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v7.0#n81
Regards,
Markus
^ permalink raw reply
* Re: [PATCH 1/9] bitfield: add FIELD_GET_SIGNED()
From: David Laight @ 2026-04-21 9:27 UTC (permalink / raw)
To: Yury Norov
Cc: Peter Zijlstra, Thomas Gleixner, Ingo Molnar, Borislav Petkov,
Dave Hansen, x86, H. Peter Anvin, Andy Lutomirski,
Jonathan Cameron, David Lechner, Nuno Sá, Andy Shevchenko,
Ping-Ke Shih, Richard Cochran, Andrew Lunn, David S. Miller,
Eric Dumazet, Jakub Kicinski, Paolo Abeni, Alexandre Belloni,
Yury Norov, Rasmus Villemoes, Hans de Goede, Linus Walleij,
Sakari Ailus, Salah Triki, Achim Gratz, Ben Collins, linux-kernel,
linux-iio, linux-wireless, netdev, linux-rtc
In-Reply-To: <aeZocbNjbvzMZO8b@yury>
On Mon, 20 Apr 2026 13:54:57 -0400
Yury Norov <ynorov@nvidia.com> wrote:
> On Mon, Apr 20, 2026 at 01:19:40PM +0200, Peter Zijlstra wrote:
> > On Fri, Apr 17, 2026 at 01:36:12PM -0400, Yury Norov wrote:
> > > The bitfields are designed in assumption that fields contain unsigned
> > > integer values, thus extracting the values from the field implies
> > > zero-extending.
> > >
> > > Some drivers need to sign-extend their fields, and currently do it like:
> > >
> > > dc_re += sign_extend32(FIELD_GET(0xfff000, tmp), 11);
> > > dc_im += sign_extend32(FIELD_GET(0xfff, tmp), 11);
> > >
> > > It's error-prone because it relies on user to provide the correct
> > > index of the most significant bit and proper 32 vs 64 function flavor.
> > >
> > > Thus, introduce a FIELD_GET_SIGNED() macro, which is the more
> > > convenient and compiles (on x86_64) to just a couple instructions:
> > > shl and sar.
> > >
> > > Signed-off-by: Yury Norov <ynorov@nvidia.com>
> > > ---
> > > include/linux/bitfield.h | 16 ++++++++++++++++
> > > 1 file changed, 16 insertions(+)
> > >
> > > diff --git a/include/linux/bitfield.h b/include/linux/bitfield.h
> > > index 54aeeef1f0ec..35ef63972810 100644
> > > --- a/include/linux/bitfield.h
> > > +++ b/include/linux/bitfield.h
> > > @@ -178,6 +178,22 @@
> > > __FIELD_GET(_mask, _reg, "FIELD_GET: "); \
> > > })
> > >
> > > +/**
> > > + * FIELD_GET_SIGNED() - extract a signed bitfield element
> > > + * @mask: shifted mask defining the field's length and position
> > > + * @reg: value of entire bitfield
> > > + *
> > > + * Returns the sign-extended field specified by @_mask from the
> > > + * bitfield passed in as @_reg by masking and shifting it down.
> > > + */
> > > +#define FIELD_GET_SIGNED(mask, reg) \
> > > + ({ \
> > > + __BF_FIELD_CHECK(mask, reg, 0U, "FIELD_GET_SIGNED: "); \
> > > + ((__signed_scalar_typeof(mask))((long long)(reg) << \
> > > + __builtin_clzll(mask) >> (__builtin_clzll(mask) + \
> > > + __builtin_ctzll(mask))));\
> > > + })
> >
> > IIRC clz is count-leading-zeros and ctz is count-trailing-zeros. Most of
> > the other FIELD things use __bf_shf() which is defined in terms of ffs -
> > 1 (which is another way of writing ctz).
> >
> > So how about you start by redefining __bf_shf() in ctz, and then add
> > another helper for the clz and write the thing something like:
> >
> > ((long long)(reg) << __bf_clz(mask)) >> (__bf_clz(mask) + __bf_shf(mask));
>
> So...
>
> I like the shorter form, but whatever we add in the bitfield.h - we'll
> have to support it.
>
> For example, __bf_shf() wasn't intended to be used outsize of the
> header, thus double underscored. But there's over 100 external users
> now. And to make it worse, it's broken for GCC 14 and earlier:
For anyone who hasn't followed the gory details it isn't 'very broken'.
Basically __builtin_ffsll() doesn't always generate an 'integer constant
expression' from constant input so you can get a compile fail.
> https://lore.kernel.org/all/20260409-field-prep-fix-v1-1-f0e9ae64f63c@imgtec.com/
>
> So needs to get fixed.
>
> The bitfield.h has two __bf macros: __bf_shf() and __bf_cast_unsigned().
> They are thin wrappers,
__bf_cast_unsigned() isn't exactly thin.
David
> but after all do something with the corresponding
> builtins output. The __bf_cls() would be a pure renaming. I'm OK with
> that, but some people don't:
>
> https://lore.kernel.org/all/20260303182845.250bb2de@kernel.org/
>
> That's why I didn't make FIELD_GET_SIGNED() implementation looking nicer.
> If you strongly prefer the shorter version, I can do that in v2.
>
> > Also, since the order of the shifts is rather important, I think it
> > makes sense to add this extra pair of (), even when not strictly needed,
> > just to make it easier to read.
>
> Sure, will do.
>
^ permalink raw reply
* Re: [PATCH net-deletions] net: remove unused ATM protocols and legacy ATM device drivers
From: David Woodhouse @ 2026-04-21 9:26 UTC (permalink / raw)
To: Jakub Kicinski, davem
Cc: netdev, edumazet, pabeni, andrew+netdev, horms, corbet, skhan,
linux, tsbogend, maddy, mpe, npiggin, chleroy, 3chas3, razor,
idosch, jani.nikula, mchehab+huawei, tytso, herbert, geert,
ebiggers, johannes.berg, jonathan.cameron, kees, kuniyu,
fourier.thomas, andriy.shevchenko, rdunlap, akpm, linux-doc,
linux-mips, linuxppc-dev, bridge
In-Reply-To: <20260421021943.1295109-1-kuba@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 1842 bytes --]
On Mon, 2026-04-20 at 19:19 -0700, Jakub Kicinski wrote:
> Remove the ATM protocol modules and PCI/SBUS ATM device drivers
> that are no longer in active use.
>
> The ATM core protocol stack, PPPoATM, and USB DSL modem drivers
> (drivers/usb/atm/) are retained in-tree to maintain PPP over ATM
> (PPPoA) support for DSL connections.
>
> Removed ATM protocol modules:
> - net/atm/clip.c - Classical IP over ATM (RFC 2225)
> - net/atm/br2684.c - RFC 2684 bridged protocols
I believe PPPoE over BR2684 is also used on ADSL lines.
https://git.kernel.org/torvalds/c/ae088d663bee strongly seems to imply
that I used to use it myself, or at least was *able* to switch to it
for testing (although I could have sworn I mostly used PPPoA).
> - net/atm/lec.c - LAN Emulation Client (LANE)
> - net/atm/mpc.c, mpoa_caches.c, mpoa_proc.c - Multi-Protocol Over ATM
>
> Removed PCI/SBUS ATM device drivers (drivers/atm/):
> - adummy, atmtcp - software/testing ATM devices
> - eni - Efficient Networks ENI155P (OC-3, ~1995)
> - fore200e - FORE Systems 200E PCI/SBUS (OC-3, ~1999)
> - he - ForeRunner HE (OC-3/OC-12, ~2000)
> - idt77105 - IDT 77105 25 Mbps ATM PHY
> - idt77252 - IDT 77252 NICStAR II (OC-3, ~2000)
> - iphase - Interphase ATM PCI (OC-3/DS3/E3)
> - lanai - Efficient Networks Speedstream 3010
> - nicstar - IDT 77201 NICStAR (155/25 Mbps, ~1999)
> - solos-pci - Traverse Technologies ADSL2+ PCI (defunct vendor)
Traverse still exists: https://traverse.com.au/
I suspect they don't have a huge amount of interest in the Solos any
more, or the Geode-based SBC they sold with two of them on-board. But
OpenWrt does still support them, and I even have one here (although no
ADSL line to test it with). They were briefly popular as fully Linux-
supported ADSL routers.
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5069 bytes --]
^ permalink raw reply
* Re: [PATCH net] netdevsim: Initialize all fields of ip header when building dummy sk_buff
From: Breno Leitao @ 2026-04-21 9:12 UTC (permalink / raw)
To: Nikola Z. Ivanov
Cc: kuba, andrew+netdev, davem, edumazet, pabeni, netdev,
linux-kernel
In-Reply-To: <9ce273bd-6912-4442-8672-4c89bebf32ed@gmail.com>
On Tue, Apr 21, 2026 at 11:54:19AM +0300, Nikola Z. Ivanov wrote:
> On 4/21/26 11:19 AM, Breno Leitao wrote:
> > On Tue, Apr 21, 2026 at 10:37:38AM +0300, Nikola Z. Ivanov wrote:
> > >
> > > Closes: https://syzkaller.appspot.com/bug?extid=23d7fcd204e3837866ff
> >
> > How do you check in the report above that the missig un-initialized
> > fields are "tos" and "id"?
>
> I don't think it is visible here, my guess would
> be because the checksum calculator walks the
> header in small chunks instead of referencing
> its fields.
>
> The whole "KMSAN: uninit-value in irqentry_exit_to_kernel_mode_preempt"
> doesn't really sound quite right.
That's precisely my question - how does this fix relate to that specific
report?
Were you able to reproduce the KMSAN report?
Thanks for the quick answer,
--breno
^ permalink raw reply
* Re: [PATCH net v3 1/1] net: l3mdev: Reject non-L3 uppers in slave helpers
From: Ido Schimmel @ 2026-04-21 9:10 UTC (permalink / raw)
To: Ren Wei
Cc: netdev, idosch, dsahern, davem, edumazet, kuba, pabeni, horms,
jiri, yifanwucs, tomapufckgml, yuantan098, bird, royenheart
In-Reply-To: <20260420182640.GA1027405@shredder>
On Mon, Apr 20, 2026 at 09:26:50PM +0300, Ido Schimmel wrote:
> On Mon, Apr 20, 2026 at 02:32:08PM +0300, Ido Schimmel wrote:
> > On Sun, Apr 19, 2026 at 10:53:32PM +0800, Ren Wei wrote:
> > > From: Haoze Xie <royenheart@gmail.com>
> > >
> > > Several l3mdev slave-side helpers resolve an upper device and then use
> > > l3mdev_ops without first proving that the resolved device is still a
> > > valid L3 master.
> > >
> > > During slave transition, an RCU reader can transiently observe an upper
> > > that is not an L3 master. Guard the affected slave-resolved paths by
> > > requiring the resolved upper to still be an L3 master before using
> > > l3mdev_ops, while keeping existing L3 RX handler providers intact.
> > >
> > > Fixes: fdeea7be88b1 ("net: vrf: Set slave's private flag before linking")
> > > Cc: stable@kernel.org
> > > 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>
> > > Tested-by: Haoze Xie <royenheart@gmail.com>
> > > Signed-off-by: Haoze Xie <royenheart@gmail.com>
> > > Signed-off-by: Ao Zhou <n05ec@lzu.edu.cn>
> >
> > I think it's fine for net:
> >
> > Reviewed-by: Ido Schimmel <idosch@nvidia.com>
>
> Thought about this again. I would like to check another approach
> (synchronize_net() after clearing IFF_L3MDEV_SLAVE). Will update
> tomorrow.
Sorry about the back and forth, but I thought about it again last night
and I think that this is a better fix:
https://github.com/idosch/linux/commit/e67517758ebcddf8a1b97817e4ab0fbf82f467fe.patch
It's a minimal fix in the control plane of the VRF driver which doesn't
add more checks in the data path. I can submit it later this week unless
there are objections.
^ permalink raw reply
* Re: [RFC PATCH 1/2] kernel/notifier: replace single-linked list with double-linked list for reverse traversal
From: Petr Mladek @ 2026-04-21 9:05 UTC (permalink / raw)
To: Masami Hiramatsu
Cc: chensong_2000, rafael, lenb, mturquette, sboyd, viresh.kumar, agk,
snitzer, mpatocka, bmarzins, song, yukuai, linan122, jason.wessel,
danielt, dianders, horms, davem, edumazet, kuba, pabeni, paulmck,
frederic, mcgrof, petr.pavlu, da.gomez, samitolvanen, atomlin,
jpoimboe, jikos, mbenes, joe.lawrence, rostedt, mark.rutland,
mathieu.desnoyers, linux-modules, linux-kernel,
linux-trace-kernel, linux-acpi, linux-clk, linux-pm,
live-patching, dm-devel, linux-raid, kgdb-bugreport, netdev
In-Reply-To: <20260420144429.57b45f2beece690bceea96ec@kernel.org>
On Mon 2026-04-20 14:44:29, Masami Hiramatsu wrote:
> Hi Song,
>
> On Wed, 15 Apr 2026 15:01:37 +0800
> chensong_2000@189.cn wrote:
>
> > From: Song Chen <chensong_2000@189.cn>
> >
> > The current notifier chain implementation uses a single-linked list
> > (struct notifier_block *next), which only supports forward traversal
> > in priority order. This makes it difficult to handle cleanup/teardown
> > scenarios that require notifiers to be called in reverse priority order.
>
> What about introducing a new notification callback API that allows you
> to describe dependencies between callback functions?
>
> For example, when registering a callback, you could register a string
> as an ID and specify whether to call it before or after that ID,
> or you could register a comparison function that is called when adding
> to a list. (I prefer @name and @depends fields so that it can be easily
> maintained.)
This looks too complex. It would make sense only
when this API has more users.
Also this won't be enough for the ftrace/livepatch callbacks.
They need to be ordered against against each other. But they
also need to be called before/after all other callbacks.
For example, when the module is loaded:
+ 1st frace
+ 2nd livepatch
+ then other notifiers
See the commit c1bf08ac26e92122 ("ftrace: Be first to run code
modification on modules").
> This would allow for better dependency building when adding to the list.
> >
> > A concrete example is the ordering dependency between ftrace and
> > livepatch during module load/unload. see the detail here [1].
>
> If this only concerns notification callback issues with the ftrace
> and livepatch modules, it's far more robust to simply call the
> necessary processing directly when the modules load and unload,
> rather than registering notification callbacks externally.
>
> There are fprobe, kprobe and its trace-events, all of them are using
> ftrace as its fundation layer. In this case, I always needs to
> consider callback order when a module is unloaded.
>
> If ftrace is working as a part of module callbacks, it will conflict
> with fprobe/kprobe module callback. Of course we can reorder it with
> modifying its priority. But this is ugly, because when we introduce
> a new other feature which depends on another layer, we need to
> reorder the callback's priority number on the list.
>
> Based on the above, I don't think this can be resolved simply by
> changing the list of notification callbacks to a bidirectional list.
I agree. I would keep it as is (hardcoded).
Best Regards,
Petr
^ permalink raw reply
* Re: [PATCH iwl-net v2 0/4] iavf: fix VLAN filter state machine races
From: Simon Horman @ 2026-04-21 9:02 UTC (permalink / raw)
To: Petr Oros
Cc: netdev, Tony Nguyen, Przemek Kitszel, Andrew Lunn,
David S. Miller, Eric Dumazet, Jakub Kicinski, Paolo Abeni,
Jesse Brandeburg, Mitch Williams, Aaron Brown,
Przemyslaw Patynowski, Jedrzej Jagielski, intel-wired-lan,
linux-kernel, jacob.e.keller
In-Reply-To: <cover.1776426683.git.poros@redhat.com>
On Fri, Apr 17, 2026 at 04:29:41PM +0200, Petr Oros wrote:
> The iavf VLAN filter state machine has several design issues that lead
> to race conditions between userspace add/del calls and the watchdog
> task's virtchnl processing. Filters can get lost or leak HW resources,
> especially during interface down/up cycles and namespace moves.
...
Hi Petr,
Sashiko has a bit to say about this patch.
I'd appreciate it if you could look over that.
In particular, the feedback on patches 2 and 3 may warrant
some updates to this patchset, while I think 4 is more
in the realm of possible future work.
^ permalink raw reply
* Re: [PATCH 16/23] genirq/cpuhotplug: Use RCU to protect access of HK_TYPE_MANAGED_IRQ cpumask
From: Thomas Gleixner @ 2026-04-21 9:02 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-17-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> As HK_TYPE_MANAGED_IRQ cpumask is going to be changeable at run time,
> use RCU to protect access to the cpumask.
>
> To enable the new HK_TYPE_MANAGED_IRQ cpumask to take effect, the
> following steps can be done.
Can be done?
> 1) Update the HK_TYPE_MANAGED_IRQ cpumask to take out the newly isolated
> CPUs and add back the de-isolated CPUs.
> 2) Tear down the affected CPUs to cause irq_migrate_all_off_this_cpu()
> to be called on the affected CPUs to migrate the irqs to other
> HK_TYPE_MANAGED_IRQ housekeeping CPUs.
> 3) Bring up the previously offline CPUs to invoke
> irq_affinity_online_cpu() to allow the newly de-isolated CPUs to
> be used for managed irqs.
Which previously offline CPUs?
> diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
> index 2e8072437826..8270c4de260b 100644
> --- a/kernel/irq/manage.c
> +++ b/kernel/irq/manage.c
> @@ -263,6 +263,7 @@ int irq_do_set_affinity(struct irq_data *data, const struct cpumask *mask, bool
> housekeeping_enabled(HK_TYPE_MANAGED_IRQ)) {
> const struct cpumask *hk_mask;
>
> + guard(rcu)();
> hk_mask = housekeeping_cpumask(HK_TYPE_MANAGED_IRQ);
>
> cpumask_and(tmp_mask, mask, hk_mask);
How is this hunk related to $Subject?
Thanks,
tglx
^ permalink raw reply
* [PATCH 2/2] mfd: rsmu_spi: add 8a34002 support
From: Matthew Bystrin @ 2026-04-21 9:07 UTC (permalink / raw)
To: Lee Jones, Richard Cochran, Min Li; +Cc: linux-kernel, netdev
In-Reply-To: <20260421090710.395591-1-dev.mbstr@gmail.com>
Add separate compatible string and spi_devcie_id to support 8a34002.
Signed-off-by: Matthew Bystrin <dev.mbstr@gmail.com>
---
drivers/mfd/rsmu_spi.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/mfd/rsmu_spi.c b/drivers/mfd/rsmu_spi.c
index 55c5698e7e77..2d4ad9606aec 100644
--- a/drivers/mfd/rsmu_spi.c
+++ b/drivers/mfd/rsmu_spi.c
@@ -242,6 +242,7 @@ static void rsmu_spi_remove(struct spi_device *client)
static const struct spi_device_id rsmu_spi_id[] = {
{ "8a34000", RSMU_CM },
{ "8a34001", RSMU_CM },
+ { "8a34002", RSMU_CM },
{ "82p33810", RSMU_SABRE },
{ "82p33811", RSMU_SABRE },
{}
@@ -251,6 +252,7 @@ MODULE_DEVICE_TABLE(spi, rsmu_spi_id);
static const struct of_device_id rsmu_spi_of_match[] = {
{ .compatible = "idt,8a34000", .data = (void *)RSMU_CM },
{ .compatible = "idt,8a34001", .data = (void *)RSMU_CM },
+ { .compatible = "idt,8a34002", .data = (void *)RSMU_CM },
{ .compatible = "idt,82p33810", .data = (void *)RSMU_SABRE },
{ .compatible = "idt,82p33811", .data = (void *)RSMU_SABRE },
{}
--
2.53.0
^ permalink raw reply related
* [PATCH 1/2] mfd: rsmu_spi: fix page register setup
From: Matthew Bystrin @ 2026-04-21 9:07 UTC (permalink / raw)
To: Lee Jones, Richard Cochran, Min Li; +Cc: linux-kernel, netdev
In-Reply-To: <20260421090710.395591-1-dev.mbstr@gmail.com>
Fix writes to page register in 8A3400x family (Clock Matrix).
All calls to rsmu_write_page_register() have resulted in early return,
becase all addresses in include/linux/mfd/idt8a340_reg.h are less than
RSMU_CM_SCSR_BASE.
There were 2 separate patch series which have to be merged in one time:
mfd and ptp. The latter have been merged, the former[1] have not.
Link: https://lore.kernel.org/netdev/LV3P220MB1202F8E2FCCFBA2519B4966EA0192@LV3P220MB1202.NAMP220.PROD.OUTLOOK.COM/
Fixes: 67d6c76fc815 ("mfd: rsmu: Support 32-bit address space")
Signed-off-by: Matthew Bystrin <dev.mbstr@gmail.com>
---
drivers/mfd/rsmu_spi.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/mfd/rsmu_spi.c b/drivers/mfd/rsmu_spi.c
index 39d9be1e141f..55c5698e7e77 100644
--- a/drivers/mfd/rsmu_spi.c
+++ b/drivers/mfd/rsmu_spi.c
@@ -101,11 +101,9 @@ static int rsmu_write_page_register(struct rsmu_ddata *rsmu, u32 reg)
switch (rsmu->type) {
case RSMU_CM:
- /* Do not modify page register for none-scsr registers */
- if (reg < RSMU_CM_SCSR_BASE)
- return 0;
page_reg = RSMU_CM_PAGE_ADDR;
page = reg & RSMU_PAGE_MASK;
+ page |= RSMU_CM_SCSR_BASE;
buf[0] = (u8)(page & 0xFF);
buf[1] = (u8)((page >> 8) & 0xFF);
buf[2] = (u8)((page >> 16) & 0xFF);
--
2.53.0
^ permalink raw reply related
* [PATCH 0/2] mfd: rsmu_spi: fixes and new IC support
From: Matthew Bystrin @ 2026-04-21 9:07 UTC (permalink / raw)
To: Lee Jones, Richard Cochran, Min Li; +Cc: linux-kernel, netdev
Greetings!
First patch fixes Renesas 8A34002 SPI driver.
In my setup 8A34002 is connected to VisionFive2 via SPI. I've discovered that
upstream driver does not work:
[ 4.728771] 8a3400x-phc 8a3400x-phc.0.auto: 4.8.7, Id: 0x4002 HW Rev: 5 OTP Config Select: 0
[ 4.737389] 8a3400x-phc 8a3400x-phc.0.auto: requesting firmware 'idtcm.bin'
[ 4.744462] 8a3400x-phc 8a3400x-phc.0.auto: Direct firmware load for idtcm.bin failed with error -2
[ 4.753547] 8a3400x-phc 8a3400x-phc.0.auto: Failed at line 1273 in idtcm_load_firmware!
[ 4.761576] 8a3400x-phc 8a3400x-phc.0.auto: loading firmware failed with -2
[ 4.769411] 8a3400x-phc 8a3400x-phc.0.auto: No wait state: DPLL_SYS_STATE 0
[ 4.776374] 8a3400x-phc 8a3400x-phc.0.auto: Continuing while SYS APLL/DPLL is not locked
[ 4.785206] 8a3400x-phc 8a3400x-phc.0.auto: Unsupported MANUAL_REFERENCE: 0x00
[ 4.796930] 8a3400x-phc 8a3400x-phc.0.auto: PLL2 registered as ptp0
This being caused by a piece of code in rsmu_write_page_register() function:
if (reg < RSMU_CM_SCSR_BASE)
return 0;
All addresses in include/linux/mfd/idt8a340_reg.h are less than
RSMU_CM_SCSR_BASE so function was returning early, before any modifications to
the page register. Valid read of versions - is just a coincidence, because
default value of the page register is zero.
There were 2 separate patch series which have to be merged in one time: mfd and
ptp. The latter have been merged, the former[1] have not. As result we've got a
broken driver.
This patch can be reverted later when the second part will be ready (of course
if it is planned to do so). Any comments, Min? I could support with testing.
Also I've had a quick look into I2C part. It may also require the same kind of
fixes to work properly. But I didn't tested it. I could do some experiments and
return with patches later.
Second patch just adds support for 8A34002, which is compatible with 8A34001. As
I can see there is no need to update bindings, everything is already being done.
Link: https://lore.kernel.org/netdev/LV3P220MB1202F8E2FCCFBA2519B4966EA0192@LV3P220MB1202.NAMP220.PROD.OUTLOOK.COM/
Signed-off-by: Matthew Bystrin <dev.mbstr@gmail.com>
Matthew Bystrin (2):
mfd: rsmu_spi: fix page register setup
mfd: rsmu_spi: add 8a34002 support
drivers/mfd/rsmu_spi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH 11/23] hrtimer: Use RCU to protect access of HK_TYPE_TIMER cpumask
From: Thomas Gleixner @ 2026-04-21 8:59 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-12-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> As HK_TYPE_TIMER cpumask is going to be changeable at run time, use
As the ...
> RCU to protect access to the cpumask.
>
> The access of HK_TYPE_TIMER cpumask within hrtimers_cpu_dying() is
> protected as interrupt is disabled and all the other CPUs are stopped
interrupts are disabled
> when this function is invoked as part of the CPU tear down process.
^ permalink raw reply
* Re: [PATCH 10/23] cpu: Use RCU to protect access of HK_TYPE_TIMER cpumask
From: Thomas Gleixner @ 2026-04-21 8:57 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-11-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> As HK_TYPE_TIMER cpumask is going to be changeable at run time, use
> RCU to protect access to the cpumask.
>
> Signed-off-by: Waiman Long <longman@redhat.com>
> ---
> kernel/cpu.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/kernel/cpu.c b/kernel/cpu.c
> index bc4f7a9ba64e..0d02b5d7a7ba 100644
> --- a/kernel/cpu.c
> +++ b/kernel/cpu.c
> @@ -1890,6 +1890,8 @@ int freeze_secondary_cpus(int primary)
> cpu_maps_update_begin();
> if (primary == -1) {
> primary = cpumask_first(cpu_online_mask);
> +
> + guard(rcu)();
> if (!housekeeping_cpu(primary, HK_TYPE_TIMER))
> primary = housekeeping_any_cpu(HK_TYPE_TIMER);
housekeeping_cpu() and housekeeping_any_cpu() can operate on two
different CPU masks once the runtime update is enabled.
Seriously?
^ permalink raw reply
* Re: [PATCH 05/23] tick: Pass timer tick job to an online HK CPU in tick_cpu_dying()
From: Thomas Gleixner @ 2026-04-21 8:55 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-6-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> In tick_cpu_dying(), if the dying CPU is the current timekeeper,
> it has to pass the job over to another CPU. The current code passes
> it to another online CPU. However, that CPU may not be a timer tick
> housekeeping CPU. If that happens, another CPU will have to manually
> take it over again later. Avoid this unnecessary work by directly
> assigning an online housekeeping CPU.
>
> Use READ_ONCE/WRITE_ONCE() to access tick_do_timer_cpu in case the
> non-HK CPUs may not be in stop machine in the future.
'may not be in the future' is yet more handwaving without
content. Please write your change logs in a way so that people who have
not spent months on this can follow.
> @@ -394,12 +395,19 @@ int tick_cpu_dying(unsigned int dying_cpu)
> {
> /*
> * If the current CPU is the timekeeper, it's the only one that can
> - * safely hand over its duty. Also all online CPUs are in stop
> - * machine, guaranteed not to be idle, therefore there is no
> + * safely hand over its duty. Also all online housekeeping CPUs are
> + * in stop machine, guaranteed not to be idle, therefore there is no
> * concurrency and it's safe to pick any online successor.
> */
> - if (tick_do_timer_cpu == dying_cpu)
> - tick_do_timer_cpu = cpumask_first(cpu_online_mask);
> + if (READ_ONCE(tick_do_timer_cpu) == dying_cpu) {
> + unsigned int new_cpu;
> +
> + guard(rcu)();
What's this guard for?
> + new_cpu = cpumask_first_and(cpu_online_mask, housekeeping_cpumask(HK_TYPE_TICK));
Why has this to use housekeeping_cpumask() and does not use
tick_nohz_full_mask?
Thanks,
tglx
^ permalink raw reply
* Re: [PATCH net] netdevsim: Initialize all fields of ip header when building dummy sk_buff
From: Nikola Z. Ivanov @ 2026-04-21 8:54 UTC (permalink / raw)
To: Breno Leitao
Cc: kuba, andrew+netdev, davem, edumazet, pabeni, netdev,
linux-kernel
In-Reply-To: <aecyEArzjx8KRp8-@gmail.com>
On 4/21/26 11:19 AM, Breno Leitao wrote:
> On Tue, Apr 21, 2026 at 10:37:38AM +0300, Nikola Z. Ivanov wrote:
>> Syzbot reports a KMSAN uninit-value originating from
>> nsim_dev_trap_skb_build, with the allocation also
>> being performed in the same function.
>>
>> The cause of the KMSAN warning is a missing assignment of
>> the tos and id fields of the ip header.
>>
>> Fix this by calling skb_put_zero instead of skb_put to
>> guarantee null initialization.
>> Additionally remove the now redundant zero assignments
>> and reorder the remaining ones so that they more closely
>> match the order of the fields as they appear in the ip header.
>>
>> Closes: https://syzkaller.appspot.com/bug?extid=23d7fcd204e3837866ff
> How do you check in the report above that the missig un-initialized
> fields are "tos" and "id"?
>
> Thanks for the fix,
> --breno
Hi Breno,
I don't think it is visible here, my guess would
be because the checksum calculator walks the
header in small chunks instead of referencing
its fields.
The whole "KMSAN: uninit-value in irqentry_exit_to_kernel_mode_preempt"
doesn't really sound quite right.
Thank you!
^ permalink raw reply
* [PATCH net] net: airoha: Do not wake all netdev TX queues in airoha_qdma_wake_netdev_txqs()
From: Lorenzo Bianconi @ 2026-04-21 8:53 UTC (permalink / raw)
To: Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: linux-arm-kernel, linux-mediatek, netdev, Lorenzo Bianconi
Do not wake every netdev TX queue across all ports sharing the QDMA
running netif_tx_wake_all_queues routine in airoha_qdma_wake_netdev_txqs()
but only the ones that are mapped the specific QDMA stopped hw TX queue.
This patch can potentially avoid waking already stopped netdev TX queues
that are mapped to a different QDMA hw TX queue.
Introduce airoha_qdma_get_txq utility routine.
Fixes: b94769eb2f30 ("net: airoha: Fix possible TX queue stall in airoha_qdma_tx_napi_poll()")
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
---
drivers/net/ethernet/airoha/airoha_eth.c | 19 +++++++++++++++----
drivers/net/ethernet/airoha/airoha_eth.h | 5 +++++
2 files changed, 20 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/airoha/airoha_eth.c b/drivers/net/ethernet/airoha/airoha_eth.c
index 19f67c7dd8e1..2ca569501045 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.c
+++ b/drivers/net/ethernet/airoha/airoha_eth.c
@@ -847,13 +847,24 @@ static void airoha_qdma_wake_netdev_txqs(struct airoha_queue *q)
{
struct airoha_qdma *qdma = q->qdma;
struct airoha_eth *eth = qdma->eth;
- int i;
+ int i, qid = q - &qdma->q_tx[0];
for (i = 0; i < ARRAY_SIZE(eth->ports); i++) {
struct airoha_gdm_port *port = eth->ports[i];
+ int j;
+
+ if (!port)
+ continue;
- if (port && port->qdma == qdma)
- netif_tx_wake_all_queues(port->dev);
+ if (port->qdma != qdma)
+ continue;
+
+ for (j = 0; j < port->dev->num_tx_queues; j++) {
+ if (airoha_qdma_get_txq(qdma, j) != qid)
+ continue;
+
+ netif_wake_subqueue(port->dev, j);
+ }
}
q->txq_stopped = false;
}
@@ -1965,7 +1976,7 @@ static netdev_tx_t airoha_dev_xmit(struct sk_buff *skb,
u16 index;
u8 fport;
- qid = skb_get_queue_mapping(skb) % ARRAY_SIZE(qdma->q_tx);
+ qid = airoha_qdma_get_txq(qdma, skb_get_queue_mapping(skb));
tag = airoha_get_dsa_tag(skb, dev);
msg0 = FIELD_PREP(QDMA_ETH_TXMSG_CHAN_MASK,
diff --git a/drivers/net/ethernet/airoha/airoha_eth.h b/drivers/net/ethernet/airoha/airoha_eth.h
index 87b328cfefb0..c3ea7aadbd82 100644
--- a/drivers/net/ethernet/airoha/airoha_eth.h
+++ b/drivers/net/ethernet/airoha/airoha_eth.h
@@ -631,6 +631,11 @@ u32 airoha_rmw(void __iomem *base, u32 offset, u32 mask, u32 val);
#define airoha_qdma_clear(qdma, offset, val) \
airoha_rmw((qdma)->regs, (offset), (val), 0)
+static inline u16 airoha_qdma_get_txq(struct airoha_qdma *qdma, u16 qid)
+{
+ return qid % ARRAY_SIZE(qdma->q_tx);
+}
+
static inline bool airoha_is_lan_gdm_port(struct airoha_gdm_port *port)
{
/* GDM1 port on EN7581 SoC is connected to the lan dsa switch.
---
base-commit: a663bac71a2f0b3ac6c373168ca57b2a6e6381aa
change-id: 20260421-airoha-wake_netdev_txqs-optmization-65171ce4ebad
Best regards,
--
Lorenzo Bianconi <lorenzo@kernel.org>
^ permalink raw reply related
* [PATCH net-next] nfp: fix swapped arguments in nfp_encode_basic_qdr() calls
From: Alexey Kodanev @ 2026-04-21 8:51 UTC (permalink / raw)
To: netdev
Cc: Jakub Kicinski, Simon Horman, Andrew Lunn, David S . Miller,
Eric Dumazet, Paolo Abeni, oss-drivers, Alexey Kodanev
There is a mismatch between the passed arguments and the actual
nfp_encode_basic_qdr() function parameters names:
static int nfp_encode_basic_qdr(u64 addr, int dest_island, int cpp_tgt,
int mode, bool addr40, int isld1,
int isld0)
{
...
But "dest_island" and "cpp_tgt" are swapped at every call-site.
For example:
return nfp_encode_basic_qdr(*addr, cpp_tgt, dest_island,
mode, addr40, isld1, isld0);
As a result, nfp_encode_basic_qdr() receives "dest_island" as CPP target
type, which is always NFP_CPP_TARGET_QDR(2) for these calls, and "cpp_tgt"
as the destination island ID, which can accidentally match or be outside
the valid NFP_CPP_TARGET_* types (e.g. '-1' for any destination).
Detected using the static analysis tool - Svace.
Fixes: 4cb584e0ee7d ("nfp: add CPP access core")
Signed-off-by: Alexey Kodanev <aleksei.kodanev@bell-sw.com>
---
drivers/net/ethernet/netronome/nfp/nfpcore/nfp_target.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_target.c b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_target.c
index 79470f198a62..5c1edd143cee 100644
--- a/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_target.c
+++ b/drivers/net/ethernet/netronome/nfp/nfpcore/nfp_target.c
@@ -493,7 +493,7 @@ static int nfp_encode_basic(u64 *addr, int dest_island, int cpp_tgt,
* the address but we can verify if the existing
* contents will point to a valid island.
*/
- return nfp_encode_basic_qdr(*addr, cpp_tgt, dest_island,
+ return nfp_encode_basic_qdr(*addr, dest_island, cpp_tgt,
mode, addr40, isld1, isld0);
iid_lsb = addr40 ? 34 : 26;
@@ -504,7 +504,7 @@ static int nfp_encode_basic(u64 *addr, int dest_island, int cpp_tgt,
return 0;
case 1:
if (cpp_tgt == NFP_CPP_TARGET_QDR && !addr40)
- return nfp_encode_basic_qdr(*addr, cpp_tgt, dest_island,
+ return nfp_encode_basic_qdr(*addr, dest_island, cpp_tgt,
mode, addr40, isld1, isld0);
idx_lsb = addr40 ? 39 : 31;
@@ -530,7 +530,7 @@ static int nfp_encode_basic(u64 *addr, int dest_island, int cpp_tgt,
* be set before hand and with them select an island.
* So we need to confirm that it's at least plausible.
*/
- return nfp_encode_basic_qdr(*addr, cpp_tgt, dest_island,
+ return nfp_encode_basic_qdr(*addr, dest_island, cpp_tgt,
mode, addr40, isld1, isld0);
/* Make sure we compare against isldN values
@@ -551,7 +551,7 @@ static int nfp_encode_basic(u64 *addr, int dest_island, int cpp_tgt,
* iid<1> = addr<30> = channel<0>
* channel<1> = addr<31> = Index
*/
- return nfp_encode_basic_qdr(*addr, cpp_tgt, dest_island,
+ return nfp_encode_basic_qdr(*addr, dest_island, cpp_tgt,
mode, addr40, isld1, isld0);
isld[0] &= ~3;
--
2.25.1
^ permalink raw reply related
* Re: [PATCH 04/23] tick/nohz: Allow runtime changes in full dynticks CPUs
From: Thomas Gleixner @ 2026-04-21 8:50 UTC (permalink / raw)
To: Waiman Long, Tejun Heo, Johannes Weiner, Michal Koutný,
Jonathan Corbet, Shuah Khan, Catalin Marinas, Will Deacon,
K. Y. Srinivasan, Haiyang Zhang, Wei Liu, Dexuan Cui, Long Li,
Guenter Roeck, Frederic Weisbecker, Paul E. McKenney,
Neeraj Upadhyay, Joel Fernandes, Josh Triplett, Boqun Feng,
Uladzislau Rezki, Steven Rostedt, Mathieu Desnoyers,
Lai Jiangshan, Zqiang, Anna-Maria Behnsen, Ingo Molnar,
Chen Ridong, Peter Zijlstra, Juri Lelli, Vincent Guittot,
Dietmar Eggemann, Ben Segall, Mel Gorman, Valentin Schneider,
K Prateek Nayak, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Simon Horman
Cc: cgroups, linux-doc, linux-kernel, linux-arm-kernel, linux-hyperv,
linux-hwmon, rcu, netdev, linux-kselftest, Costa Shulyupin,
Qiliang Yuan, Waiman Long
In-Reply-To: <20260421030351.281436-5-longman@redhat.com>
On Mon, Apr 20 2026 at 23:03, Waiman Long wrote:
> Full dynticks can only be enabled if "nohz_full" boot option has been
> been specified with or without parameter. Any change in the list of
> nohz_full CPUs have to be reflected in tick_nohz_full_mask. Introduce
> a new tick_nohz_full_update_cpus() helper that can be called to update
> the tick_nohz_full_mask at run time. The housekeeping_update() function
> is modified to call the new helper when the HK_TYPE_KERNEL_NOSIE cpumask
> is going to be changed.
>
> We also need to enable CPU context tracking for those CPUs that
We need nothing. Use passive voice for change logs as requested in
documentation.
> are in tick_nohz_full_mask. So remove __init from tick_nohz_init()
> and ct_cpu_track_user() so that they be called later when an isolated
> cpuset partition is being created. The __ro_after_init attribute is
> taken away from context_tracking_key as well.
>
> Also add a new ct_cpu_untrack_user() function to reverse the action of
> ct_cpu_track_user() in case we need to disable the nohz_full mode of
> a CPU.
>
> With nohz_full enabled, the boot CPU (typically CPU 0) will be the
> tick CPU which cannot be shut down easily. So the boot CPU should not
> be used in an isolated cpuset partition.
>
> With runtime modification of nohz_full CPUs, tick_do_timer_cpu can become
> TICK_DO_TIMER_NONE. So remove the two TICK_DO_TIMER_NONE WARN_ON_ONCE()
> checks in tick-sched.c to avoid unnecessary warnings.
in tick-sched.c? Describe the functions which contain that.
> static inline void tick_nohz_task_switch(void)
> diff --git a/kernel/context_tracking.c b/kernel/context_tracking.c
> index 925999de1a28..394e432630a3 100644
> --- a/kernel/context_tracking.c
> +++ b/kernel/context_tracking.c
> @@ -411,7 +411,7 @@ static __always_inline void ct_kernel_enter(bool user, int offset) { }
> #define CREATE_TRACE_POINTS
> #include <trace/events/context_tracking.h>
>
> -DEFINE_STATIC_KEY_FALSE_RO(context_tracking_key);
> +DEFINE_STATIC_KEY_FALSE(context_tracking_key);
> EXPORT_SYMBOL_GPL(context_tracking_key);
>
> static noinstr bool context_tracking_recursion_enter(void)
> @@ -674,9 +674,9 @@ void user_exit_callable(void)
> }
> NOKPROBE_SYMBOL(user_exit_callable);
>
> -void __init ct_cpu_track_user(int cpu)
> +void ct_cpu_track_user(int cpu)
> {
> - static __initdata bool initialized = false;
> + static bool initialized;
>
> if (cpu == CONTEXT_TRACKING_FORCE_ENABLE) {
> static_branch_inc(&context_tracking_key);
> @@ -700,6 +700,15 @@ void __init ct_cpu_track_user(int cpu)
> initialized = true;
> }
>
> +void ct_cpu_untrack_user(int cpu)
> +{
> + if (!per_cpu(context_tracking.active, cpu))
> + return;
> +
> + per_cpu(context_tracking.active, cpu) = false;
> + static_branch_dec(&context_tracking_key);
> +}
> +
Why is this in a patch which makes tick/nohz related changes? This is a
preparatory change, so make it that way and do not bury it inside
something else.
> +/* Get the new set of run-time nohz CPU list & update accordingly */
> +void tick_nohz_full_update_cpus(struct cpumask *cpumask)
> +{
> + int cpu;
> +
> + if (!tick_nohz_full_running) {
> + pr_warn_once("Full dynticks cannot be enabled without the nohz_full kernel boot parameter!\n");
That's the result of this enforced enable hackery. Make this work
properly.
> + return;
> + }
> +
> + /*
> + * To properly enable/disable nohz_full dynticks for the affected CPUs,
> + * the new nohz_full CPUs have to be copied to tick_nohz_full_mask and
> + * ct_cpu_track_user/ct_cpu_untrack_user() will have to be called
> + * for those CPUs that have their states changed. Those CPUs should be
> + * in an offline state.
> + */
> + for_each_cpu_andnot(cpu, cpumask, tick_nohz_full_mask) {
> + WARN_ON_ONCE(cpu_online(cpu));
> + ct_cpu_track_user(cpu);
> + cpumask_set_cpu(cpu, tick_nohz_full_mask);
> + }
> +
> + for_each_cpu_andnot(cpu, tick_nohz_full_mask, cpumask) {
> + WARN_ON_ONCE(cpu_online(cpu));
> + ct_cpu_untrack_user(cpu);
> + cpumask_clear_cpu(cpu, tick_nohz_full_mask);
> + }
> +}
So this writes to tick_nohz_full_mask while other CPUs can access
it. That's just wrong and I'm not at all interested in the resulting
KCSAN warnings.
tick_nohz_full_mask needs to become a RCU protected pointer, which is
updated once the new mask is established in a separately allocated one.
Thanks,
tglx
^ 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