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 <jpoim...@redhat.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
