Re: [PATCH v2] uprobes: fix incorrect lockdep condition in filter_chain()

[Google]

On Wed, 28 Jan 2026 10:16:11 -0800
Breno Leitao <leitao@xxxxxxxxxx> wrote:

> The list_for_each_entry_rcu() in filter_chain() uses
> rcu_read_lock_trace_held() as the lockdep condition, but the function
> holds consumer_rwsem, not the RCU trace lock.
> 
> This gives me the following output when running with some locking debug
> option enabled:
> 
>   kernel/events/uprobes.c:1141 RCU-list traversed in non-reader section!!
>     filter_chain
>     register_for_each_vma
>     uprobe_unregister_nosync
>     __probe_event_disable
> 
> Remove the incorrect lockdep condition since the rwsem provides
> sufficient protection for the list traversal.
> 

Looks good to me.

Acked-by: Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>

Thanks,

> Cc: stable@xxxxxxxxxxxxxxx
> Fixes: cc01bd044e6a ("uprobes: travers uprobe's consumer list locklessly under SRCU protection")
> Acked-by: Oleg Nesterov <oleg@xxxxxxxxxx>
> Acked-by: Andrii Nakryiko <andrii@xxxxxxxxxx>
> Signed-off-by: Breno Leitao <leitao@xxxxxxxxxx>
> ---
> Changes in v2:
> - updated the "fixes" tag (Oleg)
> - Link to v1: https://patch.msgid.link/20260128-uprobe_rcu-v1-1-d41316763799@xxxxxxxxxx
> ---
>  kernel/events/uprobes.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index d546d32390a81..726d13b375f3d 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -1138,7 +1138,7 @@ static bool filter_chain(struct uprobe *uprobe, struct mm_struct *mm)
>  	bool ret = false;
>  
>  	down_read(&uprobe->consumer_rwsem);
> -	list_for_each_entry_rcu(uc, &uprobe->consumers, cons_node, rcu_read_lock_trace_held()) {
> +	list_for_each_entry(uc, &uprobe->consumers, cons_node) {
>  		ret = consumer_filter(uc, mm);
>  		if (ret)
>  			break;
> 
> ---
> base-commit: 1f97d9dcf53649c41c33227b345a36902cbb08ad
> change-id: 20260128-uprobe_rcu-e21867ab4c1b
> 
> Best regards,
> --  
> Breno Leitao <leitao@xxxxxxxxxx>
> 


-- 
Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>