On Thu, Jul 11, 2024 at 06:06:53PM +0200, Oleg Nesterov wrote:
> I'll try to actually apply the whole series and read the code tomorrow.
> Right now I can't understand this change... Just one question for now.
>
> On 07/11, Peter Zijlstra wrote:
> >
> > @@ -1956,11 +1960,13 @@ static void prepare_uretprobe(struct upr
> > * attack from user-space.
> > */
> > uprobe_warn(current, "handle tail call");
> > - goto err_uprobe;
> > + goto err_mem;
> > }
> > orig_ret_vaddr = utask->return_instances->orig_ret_vaddr;
> > }
> >
> > + ri->srcu_idx = __srcu_read_lock(&uretprobes_srcu);
> > + ri->uprobe = uprobe;
>
> It seems that, if we race with _unregister, this __srcu_read_lock()
> can happen after call_srcu(uprobes_srcu, uprobe, uprobe_free_stage1)
> was already called...
>
> In this case read_lock "has no effect" in that uprobe_free_stage1()
> can run before free_ret_instance() does srcu_read_unlock(ri->srcu_idx).
>
> Perhaps it is fine, uprobe_free_stage1() does another call_srcu(),
> but somehow I got lost.
>
> Could you re-check this logic? Most probably I missed something, but still...
handle_swbp()
guard(srcu)(&uprobes_srcu);
handle_chain();
prepare_uretprobe()
__srcu_read_lock(&uretprobe_srcu);
vs
uprobe_free_stage2
kfree(uprobe)
uprobe_free_stage1
call_srcu(&uretprobe_srcu, &uprobe->rcu, uprobe_free_stage2);
put_uprobe()
if (refcount_dec_and_test)
call_srcu(&uprobes_srcu, &uprobe->rcu, uprobe_free_stage1);
So my thinking was since we take uretprobe_srcu *inside* uprobe_srcu,
this reference must be visible before we execute stage1, and as such
stage2 cannot complete prematurely.
