[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200516171223.GC2639@paulmck-ThinkPad-P72>
Date: Sat, 16 May 2020 10:12:23 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: "Joel Fernandes (Google)" <joel@...lfernandes.org>
Cc: linux-kernel@...r.kernel.org, Andy Lutomirski <luto@...nel.org>,
Frederic Weisbecker <fweisbec@...il.com>, frextrite@...il.com,
Ingo Molnar <mingo@...hat.com>,
Josh Triplett <josh@...htriplett.org>, kernel-team@...roid.com,
Lai Jiangshan <jiangshanlai@...il.com>,
madhuparnabhowmik04@...il.com,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
peterz@...radead.org, Petr Mladek <pmladek@...e.com>,
rcu@...r.kernel.org, rostedt@...dmis.org, tglx@...utronix.de,
vpillai@...italocean.com
Subject: Re: [PATCH v3 0/5] RCU dyntick nesting counter cleanups for rcu -dev
On Mon, May 04, 2020 at 10:44:13AM -0700, Paul E. McKenney wrote:
> On Mon, May 04, 2020 at 10:15:32AM -0700, Paul E. McKenney wrote:
> > On Mon, May 04, 2020 at 08:05:00AM -0400, Joel Fernandes (Google) wrote:
> > > These patches clean up the usage of dynticks nesting counters simplifying the
> > > code, while preserving the usecases.
> > >
> > > It is a much needed simplification, makes the code less confusing, and prevents
> > > future bugs such as those that arise from forgetting that the
> > > dynticks_nmi_nesting counter is not a simple counter and can be "crowbarred" in
> > > common situations.
> > >
> > > rcutorture testing with all TREE RCU configurations succeed with
> > > CONFIG_RCU_EQS_DEBUG=y and CONFIG_PROVE_LOCKING=y.
> > >
> > > v1->v2:
> > > - Rebase on v5.6-rc6
> > >
> > > v2->v3:
> > > - Rebase on rcu/dev with adjustments for tasks-RCU.
> >
> > Thank you!
> >
> > But this does not apply to any of v5.6-rc6, v5.7-rc1, or v5.7-rc2.
> >
> > Where should I be trying to apply it?
>
> OK, morning blindness overcome. I new see the "rcu/dev" in v2->v3.
>
> Please accept my apologies for the noise.
And I have allegedly resolved the conflicts with Thomas's and Peter's
series, or at least the noinstr-rcu-nmi-2020-05-15 branch of that series.
At least one conflict was completely invisible to "git rebase" (but
fortunately blindingly obvious to the compiler). This naturally makes
me suspect that additional adjustments might be needed. Especially
given that misplaced instrumentation_begin() and instrumentation_end()
calls are invisible not only to the compiler, but also to rcutorture in
my setup. (For example, tracing before instrumentation_begin() or after
instrumentation_end() is a bug.)
So could you please carefully check these commits? They are now on the
-rcu tree's "dev" branch.
Thanx, Paul
Powered by blists - more mailing lists