Messages in this thread | | | Date | Wed, 26 Aug 2020 11:51:44 +0200 | From | peterz@infradea ... | Subject | Re: INFO: rcu detected stall in smp_call_function |
| |
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.
| |