All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: "Kirill A. Shutemov" <kirill@shutemov.name>,
	linux-kernel@vger.kernel.org,
	Dipankar Sarma <dipankar@in.ibm.com>,
	Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Lai Jiangshan <laijs@cn.fujitsu.com>,
	arjan.van.de.ven@intel.com
Subject: Re: linux-next-20110923: warning kernel/rcutree.c:1833
Date: Wed, 5 Oct 2011 18:59:24 -0700	[thread overview]
Message-ID: <20111006015924.GA2827@linux.vnet.ibm.com> (raw)
In-Reply-To: <20111006005858.GA27619@linux.vnet.ibm.com>

On Wed, Oct 05, 2011 at 05:58:58PM -0700, Paul E. McKenney wrote:
> On Mon, Oct 03, 2011 at 09:30:36AM -0700, Paul E. McKenney wrote:
> > On Mon, Oct 03, 2011 at 03:03:48PM +0200, Frederic Weisbecker wrote:
> > > On Sun, Oct 02, 2011 at 05:32:47PM -0700, Paul E. McKenney wrote:
> > > > > > -void rcu_irq_enter(void)
> > > > > > +int rcu_is_cpu_idle(void)
> > > > > >  {
> > > > > > -	rcu_exit_nohz();
> > > > > > +	return (atomic_read(&__get_cpu_var(rcu_dynticks).dynticks) & 0x1) == 0;
> > > > > >  }
> > > > > 
> > > > > So that's not used in this patch but it's interesting for me
> > > > > to backport "rcu: Detect illegal rcu dereference in extended quiescent state".
> > > > 
> > > > Yep, that is why it is there.
> > > 
> > > Ok.
> > > 
> > > > 
> > > > > The above should be read from a preempt disabled section though
> > > > > (remember "rcu: Fix preempt-unsafe debug check of rcu extended quiescent state")
> > > > 
> > > > Yes, and that is why the last line of the header comment reads "The
> > > > caller must have at least disabled preemption."  Disabling preemption
> > > > is not necessary in Tiny RCU because there is no other CPU for the task
> > > > to go to.  (Right?)
> > > 
> > > Right.
> > > 
> > > > > Those functions should probably lay in a separate patch. But I don't mind
> > > > > much keeping the things as is and use these APIs in my next patches though.
> > > > > I'll just fix the preempt enabled thing above.
> > > > 
> > > > Or were you saying that you wish to make calls to rcu_is_cpu_idle()
> > > > that have preemption enabled?
> > > 
> > > Yeah. That's going to be called from places like rcu_read_lock_held()
> > > and things like this that don't need to disable preemption themselves.
> > > 
> > > Would be better to disable preemption from that function.
> > 
> > Hmmm...  This might be a good use for the "drive-by" per-CPU access
> > functions.
> > 
> > No, that doesn't work.  We could pick up the pointer, switch to another
> > CPU, the original CPU could run a task that blocks before we start running,
> > and then we could incorrectly decide that we were running in idle context,
> > issuing a spurious warning.  This approach would only work in environments
> > that (unlike the Linux kernel) mapped all the per-CPU variables to the
> > same virtual address on all CPUs.  (DYNIX/ptx did this, but this leads
> > to other problems, like being unable to reasonably access other CPUs'
> > variables.  Double mapping has other issues on some architectures.)
> > 
> > OK, agreed.  I will make this function disable preemption.
> > 
> > > > And I can split the patch easily enough while keeping the diff the same,
> > > > so you should be able to do your porting on top of the existing code.
> > > 
> > > No I'm actually pretty fine with the current state. Whether that's defined
> > > in this patch or a following one is actually not important.
> > 
> > Fair enough!
> 
> And here is an update that might handle an irq entry/exit miscounting
> problem.  Thanks to Arjan van de Ven for pointing out that my earlier
> approach would in fact miscount irq entries/exits in face of things like
> upcalls to user-mode helpers.
> 
> This is experimental, and might well hurt more than it helps.  Testing
> ongoing.  Applies on top of my "Track idleness independent of idle tasks"
> commit.  Right...  And the tracing relies on a later patch, so feel free
> to yank the calls to trace_rcu_dyntick() on the off-chance that you are
> crazy enough to actually try this.
> 
> Thoughts?

For the code currently in mainline, I hasten to add.  For your use,
Frederic, I need to handle the case where a user process is idle
from an RCU viewpoint.  I will be looking into this, but in the
meantime I wanted to prove/disprove that this is the source of the
failures that I have been seeing.

							Thanx, Paul

> ------------------------------------------------------------------------
> 
> Not-yet-signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> 
> diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> index 06c0ed4..d4247e0 100644
> --- a/kernel/rcutree.c
> +++ b/kernel/rcutree.c
> @@ -356,6 +356,11 @@ void rcu_idle_enter(void)
>  
>  	local_irq_save(flags);
>  	rdtp = &__get_cpu_var(rcu_dynticks);
> +	if (!idle_cpu(smp_processor_id())) {
> +		trace_rcu_dyntick("--|", rdtp->dynticks_nesting);
> +		local_irq_restore(flags);
> +		return;
> +	}
>  	if (--rdtp->dynticks_nesting) {
>  		trace_rcu_dyntick("--=", rdtp->dynticks_nesting);
>  		local_irq_restore(flags);
> @@ -384,6 +389,11 @@ void rcu_idle_exit(void)
>  
>  	local_irq_save(flags);
>  	rdtp = &__get_cpu_var(rcu_dynticks);
> +	if (!idle_cpu(smp_processor_id())) {
> +		trace_rcu_dyntick("++|", rdtp->dynticks_nesting);
> +		local_irq_restore(flags);
> +		return;
> +	}
>  	if (rdtp->dynticks_nesting++) {
>  		trace_rcu_dyntick("++=", rdtp->dynticks_nesting);
>  		local_irq_restore(flags);

  reply	other threads:[~2011-10-06  2:00 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-25  0:24 linux-next-20110923: warning kernel/rcutree.c:1833 Kirill A. Shutemov
2011-09-25  5:08 ` Paul E. McKenney
2011-09-25 11:26   ` Kirill A. Shutemov
2011-09-25 13:06     ` Frederic Weisbecker
2011-09-25 14:19       ` Kirill A. Shutemov
2011-09-25 16:48       ` Paul E. McKenney
2011-09-26  1:04         ` Frederic Weisbecker
2011-09-26  1:10           ` Frederic Weisbecker
2011-09-26  1:26             ` Paul E. McKenney
2011-09-26  1:41               ` Paul E. McKenney
2011-09-26  9:39                 ` Frederic Weisbecker
2011-09-26 22:34                   ` Paul E. McKenney
2011-09-27 12:07                     ` Frederic Weisbecker
2011-09-26  9:42                 ` Frederic Weisbecker
2011-09-26 22:35                   ` Paul E. McKenney
2011-09-26  9:20               ` Frederic Weisbecker
2011-09-26 22:50                 ` Paul E. McKenney
2011-09-27 12:16                   ` Frederic Weisbecker
2011-09-27 18:01                     ` Paul E. McKenney
2011-09-28 12:31                       ` Frederic Weisbecker
2011-09-28 18:40                         ` Paul E. McKenney
2011-09-28 23:46                           ` Frederic Weisbecker
2011-09-29  0:55                             ` Paul E. McKenney
2011-09-29  4:49                               ` Paul E. McKenney
2011-09-29 12:30                               ` Frederic Weisbecker
2011-09-29 17:12                                 ` Paul E. McKenney
2011-09-29 17:19                                   ` Paul E. McKenney
2011-09-29 23:18                                     ` Paul E. McKenney
2011-09-30 13:11                                   ` Frederic Weisbecker
2011-09-30 15:29                                     ` Paul E. McKenney
2011-09-30 19:24                                       ` Paul E. McKenney
2011-10-01  4:34                                         ` Paul E. McKenney
2011-10-01 12:24                                         ` Frederic Weisbecker
2011-10-01 12:28                                           ` Frederic Weisbecker
2011-10-01 16:35                                             ` Paul E. McKenney
2011-10-01 17:07                                           ` Paul E. McKenney
2011-10-02  3:23                                             ` Paul E. McKenney
2011-10-02 11:45                                               ` Frederic Weisbecker
2011-10-02 22:50                                         ` Frederic Weisbecker
2011-10-03  0:28                                           ` Paul E. McKenney
2011-10-03 12:59                                             ` Frederic Weisbecker
2011-10-03 16:22                                               ` Paul E. McKenney
2011-10-03 17:11                                                 ` Frederic Weisbecker
2011-10-02 23:07                                         ` Frederic Weisbecker
2011-10-03  0:32                                           ` Paul E. McKenney
2011-10-03 13:03                                             ` Frederic Weisbecker
2011-10-03 16:30                                               ` Paul E. McKenney
2011-10-06  0:58                                                 ` Paul E. McKenney
2011-10-06  1:59                                                   ` Paul E. McKenney [this message]
2011-10-06 12:11                                                   ` Frederic Weisbecker
2011-10-06 18:44                                                     ` Paul E. McKenney
2011-10-06 23:44                                                       ` Paul E. McKenney
2011-09-26  1:25           ` Paul E. McKenney
2011-09-26  8:48             ` Frederic Weisbecker
2011-09-26  8:49             ` Frederic Weisbecker
2011-09-26 22:30               ` Paul E. McKenney
2011-09-27 11:55                 ` Frederic Weisbecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111006015924.GA2827@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=arjan.van.de.ven@intel.com \
    --cc=dipankar@in.ibm.com \
    --cc=fweisbec@gmail.com \
    --cc=kirill@shutemov.name \
    --cc=laijs@cn.fujitsu.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.