On 10/19, Andrii Nakryiko wrote: > > On Mon, Oct 19, 2026 at 3:51 AM Oleg Nesterov <[email protected]> wrote: > > > > On 10/19, Binbin Deng wrote: > > > > > > consumer_add() publishes a consumer on uprobe->consumers > > > before assigning its session ID. handler_chain() traverses the consumer > > > list under the trace RCU read-side critical section and can therefore > > > observe the new consumer while uc->id still contains its initial value. > > > > > > The race is reachable when an uprobe at the same inode:offset is already > > > active and a task hits its entry breakpoint while another CPU registers a > > > second session consumer. handler_chain() may store the stale ID in the > > > return_instance consumer array. By the time the function returns, > > > uc->id has been assigned a nonzero value, so return_consumer_find() fails > > > to match the saved ID and the session ret_handler is incorrectly skipped. > > > > I guess we don't really care, this doesn't differ from the case when > > consumer_add() is called right after list_for_each_entry_rcu() in > > handler_chain(). > > that uc->id is important for "uprobe session" semantics,
Yes, but > which seems a > bit different situation compared to barely missing consumer_add() in > handler_chain(), I must have missed something... If handler_chain() misses consumer_add() then push_consumer(uc->id) won't be called. This means that then later handle_uretprobe_chain() -> return_consumer_find(uc->id) will equally fail? > but regardless, the fix looks good, we should apply it > > Acked-by: Andrii Nakryiko <[email protected]> Agreed, I have acked it too. Oleg.
