[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190521125319.04ac8b6c@gandalf.local.home>
Date: Tue, 21 May 2019 12:53:19 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Johannes Erdfelt <johannes@...felt.com>,
Joe Lawrence <joe.lawrence@...hat.com>,
Jessica Yu <jeyu@...nel.org>, Jiri Kosina <jikos@...nel.org>,
Miroslav Benes <mbenes@...e.cz>,
Ingo Molnar <mingo@...hat.com>, live-patching@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: Oops caused by race between livepatch and ftrace
On Tue, 21 May 2019 11:42:27 -0500
Josh Poimboeuf <jpoimboe@...hat.com> wrote:
> Hm. I suppose using ftrace_lock might be less risky since that lock is
> only used internally by ftrace (up until now). But I think it would
> also make less sense because the text_mutex is supposed to protect code
> patching. And presumably ftrace_lock is supposed to be ftrace-specific.
>
> Here's the latest patch, still using text_mutex. I added some lockdep
> assertions to ensure the permissions toggling functions are always
> called with text_mutex. It's running through 0-day right now. I can
> try to run it through various tests with CONFIG_LOCKDEP.
Yeah, text_mutex probably does make more sense. ftrace_mutex was around
before text_mutex as ftrace was the first one to do the runtime
patching (after boot has finished). It wasn't until we introduced
text_poke that we decided to create the text_mutex locking as well.
>
>
> From: Josh Poimboeuf <jpoimboe@...hat.com>
> Subject: [PATCH] livepatch: Fix ftrace module text permissions race
Thanks,
I'll try to find some time to test this as well.
-- Steve
Powered by blists - more mailing lists