[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200517161531.GR2869@paulmck-ThinkPad-P72>
Date: Sun, 17 May 2020 09:15:31 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: "Joel Fernandes (Google)" <joel@...lfernandes.org>,
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, vpillai@...italocean.com
Subject: Re: [PATCH v3 0/5] RCU dyntick nesting counter cleanups for rcu -dev
On Sun, May 17, 2020 at 12:26:43PM +0200, Thomas Gleixner wrote:
> Paul,
>
> "Paul E. McKenney" <paulmck@...nel.org> writes:
> > 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.)
>
> there is tooling to verify that. If you merge
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git entry-v7-full
>
> into your dev branch (trivial conflict) and after building it, run:
>
> objtool check -fal $BUILDIR/vmlinux.o
The conflict was trivial, but for future reference, where should I be
getting the proper objtool from?
Thanx, Paul
Powered by blists - more mailing lists