[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <nycvar.YFH.7.76.1905291315310.1962@cbobk.fhfr.pm>
Date: Wed, 29 May 2019 13:17:21 +0200 (CEST)
From: Jiri Kosina <jikos@...nel.org>
To: Steven Rostedt <rostedt@...dmis.org>
cc: Josh Poimboeuf <jpoimboe@...hat.com>,
Johannes Erdfelt <johannes@...felt.com>,
Joe Lawrence <joe.lawrence@...hat.com>,
Jessica Yu <jeyu@...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, Steven Rostedt 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, Jessica, any final word on this?
Thanks,
--
Jiri Kosina
SUSE Labs
Powered by blists - more mailing lists