From: Rusty Russell <rusty@rustcorp.com.au>
To: Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Takao Indoh <indou.takao@jp.fujitsu.com>,
Frederic Weisbecker <fweisbec@gmail.com>,
Ingo Molnar <mingo@redhat.com>,
Ananth N Mavinakayanahalli <ananth@in.ibm.com>,
Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>,
"David S. Miller" <davem@davemloft.net>,
linux-kernel@vger.kernel.org
Subject: Re: ftrace/kprobes: Warning when insmod two modules
Date: Tue, 22 Apr 2014 13:21:18 +0930 [thread overview]
Message-ID: <87bnvunhs9.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20140324105939.7f823b81@gandalf.local.home>
Steven Rostedt <rostedt@goodmis.org> writes:
> On Mon, 24 Mar 2014 20:26:05 +0900
> Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com> wrote:
>
>
>> Thank you for reporting with this pretty backtrace :)
>> Steven, I think this is not the kprobe bug but ftrace (and perhaps, module).
>
> Looks to be more of a module issue than a ftrace issue.
>
>>
>> If the ftrace can set loading module text read only before the module subsystem
>> expected, I think it should be protected by the module subsystem itself
>> (e.g. set_all_modules_text_ro(rw) skips the modules which is MODULE_STATE_COMING)
>>
>
> Does this patch fix it?
>
> In-review-off-by: Steven Rostedt <rostedt@goodmis.org>
Sorry, was on paternity leave.
I'm always nervous about adding more states, since every place which
examines the state has to be audited.
We set the mod->state to MOD_STATE_COMING in complete_formation;
why don't we set NX there instead? It also makes more sense to
set NX before we hit parse_args() which can execute code in the module.
In fact, we should probably call the notifier there too, so people
can breakpoint/tracepoint/etc parameter calls.
Of course, this means that we set NX before the notifier; does anything
break?
Subject: module: set nx before marking module MODULE_STATE_COMING.
This prevents a WARN_ON() where ftrace calls set_all_modules_text_ro()
which races with the module setting its own set_section_ro_nx().
It also means we're NX protected before we call parse_args(), which
can execute module code.
This means that the notifiers will be called on a module which
is already NX, so that may cause problems.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff --git a/kernel/module.c b/kernel/module.c
index 11869408f79b..83a437e5d429 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3023,21 +3023,6 @@ static int do_init_module(struct module *mod)
*/
current->flags &= ~PF_USED_ASYNC;
- blocking_notifier_call_chain(&module_notify_list,
- MODULE_STATE_COMING, mod);
-
- /* Set RO and NX regions for core */
- set_section_ro_nx(mod->module_core,
- mod->core_text_size,
- mod->core_ro_size,
- mod->core_size);
-
- /* Set RO and NX regions for init */
- set_section_ro_nx(mod->module_init,
- mod->init_text_size,
- mod->init_ro_size,
- mod->init_size);
-
do_mod_ctors(mod);
/* Start the module */
if (mod->init != NULL)
@@ -3168,9 +3153,26 @@ static int complete_formation(struct module *mod, struct load_info *info)
/* This relies on module_mutex for list integrity. */
module_bug_finalize(info->hdr, info->sechdrs, mod);
+ /* Set RO and NX regions for core */
+ set_section_ro_nx(mod->module_core,
+ mod->core_text_size,
+ mod->core_ro_size,
+ mod->core_size);
+
+ /* Set RO and NX regions for init */
+ set_section_ro_nx(mod->module_init,
+ mod->init_text_size,
+ mod->init_ro_size,
+ mod->init_size);
+
/* Mark state as coming so strong_try_module_get() ignores us,
* but kallsyms etc. can see us. */
mod->state = MODULE_STATE_COMING;
+ mutex_unlock(&module_mutex);
+
+ blocking_notifier_call_chain(&module_notify_list,
+ MODULE_STATE_COMING, mod);
+ return 0;
out:
mutex_unlock(&module_mutex);
next prev parent reply other threads:[~2014-04-22 3:59 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-24 5:10 ftrace/kprobes: Warning when insmod two modules Takao Indoh
2014-03-24 11:26 ` Masami Hiramatsu
2014-03-24 14:27 ` Steven Rostedt
2014-03-24 14:59 ` Steven Rostedt
2014-03-25 5:54 ` Takao Indoh
2014-04-22 3:51 ` Rusty Russell [this message]
2014-04-22 5:29 ` Takao Indoh
2014-04-22 7:28 ` Masami Hiramatsu
2014-04-22 8:35 ` Takao Indoh
2014-04-23 1:26 ` Masami Hiramatsu
2014-04-23 1:56 ` Steven Rostedt
2014-04-23 2:37 ` Masami Hiramatsu
2014-04-24 6:58 ` Takao Indoh
2014-04-24 12:49 ` Steven Rostedt
2014-04-22 13:41 ` Steven Rostedt
2014-04-24 7:38 ` Rusty Russell
2014-04-24 12:21 ` Steven Rostedt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87bnvunhs9.fsf@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=ananth@in.ibm.com \
--cc=anil.s.keshavamurthy@intel.com \
--cc=davem@davemloft.net \
--cc=fweisbec@gmail.com \
--cc=indou.takao@jp.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mingo@redhat.com \
--cc=rostedt@goodmis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.