[PATCH net-next] caif: annotate phyinfo lookup under config lock

[PATCH net-next] caif: annotate phyinfo lookup under config lock

[Runyu Xiao]

cfcnfg_get_phyinfo_rcu() is used by both RCU read-side paths and config
update paths that hold cnfg->lock before adding or deleting entries from
cnfg->phys. The helper walks the list with list_for_each_entry_rcu(),
but does not tell lockdep about the config-lock-protected callers.

Pass lockdep_is_held(&cnfg->lock) to the iterator. RCU-reader callers
remain valid, and CONFIG_PROVE_RCU_LIST can now see the non-RCU
protection used by the add/delete paths.

This was found by our static analysis tool and then manually reviewed
against the current tree. The dynamic triage evidence is a
target-matched CONFIG_PROVE_RCU_LIST warning; the change is limited
to documenting the existing protection contract.

This is a lockdep annotation cleanup. It does not change CAIF phyinfo
list lifetime or update ordering.

Signed-off-by: Runyu Xiao <runyu.xiao@seu.edu.cn>
---
 net/caif/cfcnfg.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/caif/cfcnfg.c b/net/caif/cfcnfg.c
index 52509e185960..6966cc9ab640 100644
--- a/net/caif/cfcnfg.c
+++ b/net/caif/cfcnfg.c
@@ -135,7 +135,8 @@ static struct cfcnfg_phyinfo *cfcnfg_get_phyinfo_rcu(struct cfcnfg *cnfg,
 {
 	struct cfcnfg_phyinfo *phy;
 
-	list_for_each_entry_rcu(phy, &cnfg->phys, node)
+	list_for_each_entry_rcu(phy, &cnfg->phys, node,
+				lockdep_is_held(&cnfg->lock))
 		if (phy->id == phyid)
 			return phy;
 	return NULL;
-- 
2.34.1

Re: [PATCH net-next] caif: annotate phyinfo lookup under config lock

[Jakub Kicinski]

On Fri, 26 Jun 2026 12:24:40 +0800 Runyu Xiao wrote:
> cfcnfg_get_phyinfo_rcu() is used by both RCU read-side paths and config
> update paths that hold cnfg->lock before adding or deleting entries from
> cnfg->phys. The helper walks the list with list_for_each_entry_rcu(),
> but does not tell lockdep about the config-lock-protected callers.
> 
> Pass lockdep_is_held(&cnfg->lock) to the iterator. RCU-reader callers
> remain valid, and CONFIG_PROVE_RCU_LIST can now see the non-RCU
> protection used by the add/delete paths.
> 
> This was found by our static analysis tool and then manually reviewed
> against the current tree. The dynamic triage evidence is a
> target-matched CONFIG_PROVE_RCU_LIST warning; the change is limited
> to documenting the existing protection contract.

This code was removed a couple of releases ago.