[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 10 Oct 2019 11:03:26 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: LKML <linux-kernel@...r.kernel.org>, Jessica Yu <jeyu@...nel.org>,
Ingo Molnar <mingo@...nel.org>
Subject: Re: [PATCH] ftrace/module: Allow ftrace to make only loaded module
text read-write
On Thu, 10 Oct 2019 10:55:15 -0400
Steven Rostedt <rostedt@...dmis.org> wrote:
> But we have an issue with the state of the module here, as it is still
> set as MODULE_STATE_UNFORMED. Let's look at what happens if we have:
>
>
> CPU0 CPU1
> ---- ----
> echo function > current_tracer
> modprobe foo
> enable foo functions to be traced
> (foo function records not disabled)
> echo nop > current_tracer
>
> disable all functions being
> traced including foo functions
>
> arch calls set_all_modules_text_rw()
> [skips UNFORMED modules, which foo still is ]
>
> set foo's text to read-only
> foo's state to COMING
>
> tries to disable foo's functions
> foo's text is read-only
>
> BUG trying to write to ro text!!!
>
>
> Like I said, this is very subtle. It may no longer be a bug on x86
> with your patches, but it will bug on ARM or anything else that still
> uses set_all_modules_text_rw() in the ftrace prepare code.
I guess I should have commented this, but the big reason for the split
between ftrace_module_init() and ftrace_module_enable() is that we add
the nops when the module is still UNFORMED, but we only enable it when
the module is COMING or beyond, and not UNFORMED.
-- Steve
Powered by blists - more mailing lists