On Fri, Nov 08, 2024 at 09:28:17AM -0800, Andrii Nakryiko wrote: > On Fri, Nov 8, 2024 at 1:00 AM Peter Zijlstra <[email protected]> wrote: > > > > On Thu, Nov 07, 2024 at 09:14:45AM -0800, Breno Leitao wrote: > > > Acquire RCU trace lock in filter_chain() to protect > > > list_for_each_entry_rcu() iteration, protecting the list iteration in a > > > RCU read section. > > > > > > Prior to this fix, list_for_each_entry_srcu() was called without holding > > > the required lock, triggering warnings when RCU_PROVING is enabled: > > > > > > kernel/events/uprobes.c:937 RCU-list traversed without holding the > > > required lock!! > > > > > > Signed-off-by: Breno Leitao <[email protected]> > > > Fixes: cc01bd044e6a ("uprobes: travers uprobe's consumer list locklessly > > > under SRCU protection") > > > --- > > > kernel/events/uprobes.c | 2 ++ > > > 1 file changed, 2 insertions(+) > > > > > > diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c > > > index > > > fa04b14a7d72353adc440742016b813da6c812d2..afdaa45a43ac3948f7983175eda808c989e8738a > > > 100644 > > > --- a/kernel/events/uprobes.c > > > +++ b/kernel/events/uprobes.c > > > @@ -1103,11 +1103,13 @@ static bool filter_chain(struct uprobe *uprobe, > > > struct mm_struct *mm) > > > bool ret = false; > > > > > > down_read(&uprobe->consumer_rwsem); > > > + rcu_read_lock_trace(); > > > list_for_each_entry_rcu(uc, &uprobe->consumers, cons_node, > > > rcu_read_lock_trace_held()) { > > > > Maybe I'm confused, but isn't uprobe->consumer list protected by > > uprobe->consumer_rwsem, which we hold for reading? > > > > That is, AFAICT this is a false positive and we should be doing this > > instead, no? > > Yep, you are absolutely right. RCU-protected traversal is important > only for handler_chain() and handle_uretprobe_chain(). Here it's all > under lock, so no need for RCU protection.
Thanks. I will update
