linux-kernel - Re: INFO: rcu detected stall in smp_call

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 26 Aug 2020 11:51:44 +0200
From:   peterz@...radead.org
To:     "Paul E. McKenney" <paulmck@...nel.org>
Cc:     syzbot <syzbot+cb3b69ae80afd6535b0e@...kaller.appspotmail.com>,
        fweisbec@...il.com, linux-kernel@...r.kernel.org, mingo@...nel.org,
        syzkaller-bugs@...glegroups.com, tglx@...utronix.de
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.