[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20201030082831.5142be16@oasis.local.home>
Date: Fri, 30 Oct 2020 08:28:31 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Miroslav Benes <mbenes@...e.cz>
Cc: linux-kernel@...r.kernel.org,
Masami Hiramatsu <mhiramat@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Josh Poimboeuf <jpoimboe@...hat.com>,
Jiri Kosina <jikos@...nel.org>, Petr Mladek <pmladek@...e.com>,
Joe Lawrence <joe.lawrence@...hat.com>,
live-patching@...r.kernel.org
Subject: Re: [PATCH 6/9] livepatch/ftrace: Add recursion protection to the
ftrace callback
On Thu, 29 Oct 2020 10:37:44 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:
> I also plan on adding code that reports when recursion has happened,
> because even if it's not a problem, recursion adds extra overhead.
I did the above (will be posting that later, maybe next week), and
found two bugs with the recursion code. :-/
One was in the nmi handling, where it never cleared the nmi bit
(because it was zero, and thus ignored), and that caused all functions
in NMI handlers to not be traced (because it thought it was a
recursion).
(see https://lore.kernel.org/r/20201030002722.766a22df@oasis.local.home)
The second was the recursion algorithm depends on the preempt_count()
being accurate, but when it transitions between context, and there's
tracing in that transition, it could falsely record it as a recursion.
I have a fix for both of these bugs and will be sending them up marked
for stable after I finish testing them.
This goes to show that the recursion reported should be implemented
(but that will be for the next merge window).
-- Steve
Powered by blists - more mailing lists