On Fri, 28 Jun 2019, Steven Rostedt wrote:
> > > > How is that supposed to work?
> > > >
> > > > ftrace
> > > > prepare()
> > > > setrw()
> > > > setro()
> > > > patch <- FAIL
> > >
> > > /me dodges frozen shark
> > >
> > > You are right of course. My brain has apparently already shut off for
> > > the day.
> > >
> > > Maybe a comment or two would help though.
> >
> > I'd actually prefer (perhaps in parallel to the comment) using the
> > __acquires() and __releases() anotations, so that sparse and friends don't
> > get confused by that either.
> >
>
> Care to send a patch? :-)
From: Jiri Kosina <jkosina@xxxxxxx>
Subject: [PATCH] ftrace/x86: anotate text_mutex split between ftrace_arch_code_modify_post_process() and ftrace_arch_code_modify_prepare()
ftrace_arch_code_modify_prepare() is acquiring text_mutex, while the
corresponding release is happening in ftrace_arch_code_modify_post_process().
This has already been documented in the code, but let's also make the fact
that this is intentional clear to the semantic analysis tools such as
sparse.
Fixes: 39611265edc1a ("ftrace/x86: Add a comment to why we take text_mutex in ftrace_arch_code_modify_prepare()")
Fixes: d5b844a2cf507 ("ftrace/x86: Remove possible deadlock between register_kprobe() and ftrace_run_update_code()")
Signed-off-by: Jiri Kosina <jkosina@xxxxxxx>
---
arch/x86/kernel/ftrace.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index d7e93b2783fd..76228525acd0 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -35,6 +35,7 @@
#ifdef CONFIG_DYNAMIC_FTRACE
int ftrace_arch_code_modify_prepare(void)
+ __acquires(&text_mutex)
{
/*
* Need to grab text_mutex to prevent a race from module loading
@@ -48,6 +49,7 @@ int ftrace_arch_code_modify_prepare(void)
}
int ftrace_arch_code_modify_post_process(void)
+ __releases(&text_mutex)
{
set_all_modules_text_ro();
set_kernel_text_ro();
--
Jiri Kosina
SUSE Labs
