On Tue, Aug 25, 2020 at 08:48:41AM -0700, Paul E. McKenney wrote:
> > Paul, I wanted to use this function, but found it has very weird
> > semantics.
> >
> > Why do you need it to (remotely) call @func when p is current? The user
> > in rcu_print_task_stall() explicitly bails in this case, and the other
> > in rcu_wait_for_one_reader() will attempt an IPI.
>
> Good question. Let me look at the invocations:
>
> o trc_wait_for_one_reader() bails on current before
> invoking try_invoke_on_locked_down_task():
>
> if (t == current) {
> t->trc_reader_checked = true;
> trc_del_holdout(t);
> WARN_ON_ONCE(t->trc_reader_nesting);
> return;
> }
>
> o rcu_print_task_stall() might well invoke on the current task,
> low though the probability of this happening might be. (The task
> has to be preempted within an RCU read-side critical section
> and resume in time for the scheduling-clock irq that will report
> the RCU CPU stall to interrupt it.)
>
> And you are right, no point in an IPI in this case.
>
> > Would it be possible to change this function to:
> >
> > - blocked task: call @func with p->pi_lock held
> > - queued, !running task: call @func with rq->lock held
> > - running task: fail.
> >
> > ?
>
> Why not a direct call in the current-task case, perhaps as follows,
> including your change above? This would allow the RCU CPU stall
> case to work naturally and without the IPI.
>
> Would that work for your use case?
It would in fact, but at this point I'd almost be inclined to stick the
IPI in as well. But small steps I suppose. So yes.
