All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Zhang, Yanmin" <yanmin_zhang@linux.intel.com>
To: Steven Rostedt <rostedt@goodmis.org>,
	"Qiu, PeiyangX" <peiyangx.qiu@intel.com>
Cc: linux-kernel@vger.kernel.org, mingo@redhat.com,
	Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [PATCH] ftrace: fix race between ftrace and insmod
Date: Tue, 15 Dec 2015 11:26:41 +0800	[thread overview]
Message-ID: <566F8871.7070408@linux.intel.com> (raw)
In-Reply-To: <566F675C.9000904@linux.intel.com>

On 2015/12/15 9:05, Zhang, Yanmin wrote:
> On 2015/12/14 23:51, Steven Rostedt wrote:
>> On Mon, 14 Dec 2015 11:16:18 +0800
>> "Qiu, PeiyangX" <peiyangx.qiu@intel.com> wrote:
>>
>>> We hit ftrace_bug report when booting Android on a 64bit ATOM SOC chip.
>>> Basically, there is a race between insmod and ftrace_run_update_code.
>>>
>>> After load_module=>ftrace_module_init, another thread jumps in to call
>>> ftrace_run_update_code=>ftrace_arch_code_modify_prepare
>>>                          =>set_all_modules_text_rw, to change all modules  
>>> as RW. Since the new module is at MODULE_STATE_UNFORMED, the text attribute
>>> is not changed. Then, the 2nd thread goes ahead to change codes.
>>> However, load_module continues to call 
>>> complete_formation=>set_section_ro_nx,  
>>> then 2nd thread would fail when probing the module's TEXT.
>>>
>>> Below patch tries to resolve it.
>>>
>>> commit a949ae560a511fe4e3adf48fa44fefded93e5c2b
>>> Author: Steven Rostedt (Red Hat) <rostedt@goodmis.org>
>>> Date:   Thu Apr 24 10:40:12 2014 -0400
>>>
>>>      ftrace/module: Hardcode ftrace_module_init() call into load_module()
>>>
>>> But it can't fully resolve the issue.
>>>
>>> THis patch holds ftrace_mutex across ftrace_module_init and
>>> complete_formation.
>>>
>>> Signed-off-by: Qiu Peiyang <peiyangx.qiu@intel.com>
>>> Signed-off-by: Zhang Yanmin <yanmin.zhang@intel.com>
>> First, this patch has major whitespace damage. All tabs are now spaces!
> This seems very hackish, although I can't think of a better way at the
> moment. But I would like not to add more code into module.c if
> possible, and just use a notifier unless there's a real reason we can't
> (as there was when we added the hook in the first place).
> We would double-check it again. It's not a good idea to change common
> module codes.

I double-checked it. If using notifier, we have to add 2 new module notification
events in enum module_state.
For example, MODULE_STATE_INITING, MODULE_STATE_INITING_FAILED.
At MODULE_STATE_INITING, call ftrace_module_init(mod);
At MODULE_STATE_INITING_FAILED, call ftrace_release_mod (or similar function);
At MODULE_STATE_COMING, call a new function which links the new start_pg
to ftrace_pages.
Such design can also fix another bug in current kernel that ftrace start_pg
of the module is not cleaned up if complete_formation fails.
However, we change module common codes. The new events only serve ftrace.

If not holding ftrace_mutex across start_pg setup and complete_formation,
some other variables are not protected well, such like ftrace_pages, 
ftrace_start_up, and so on.

Yanmin
 


  reply	other threads:[~2015-12-15  3:26 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <S1751824AbbLNCkP/20151214024015Z+230@vger.kernel.org>
2015-12-14  2:59 ` [PATCH] ftrace: fix race between ftrace and insmod Qiu, PeiyangX
2015-12-14  3:16   ` Qiu, PeiyangX
2015-12-14 15:51     ` Steven Rostedt
2015-12-15  1:05       ` Zhang, Yanmin
2015-12-15  3:26         ` Zhang, Yanmin [this message]
2015-12-15 17:37           ` Steven Rostedt
2015-12-16  0:54             ` Zhang, Yanmin
2015-12-16 10:28             ` Zhang, Yanmin
2015-12-16 14:28               ` Steven Rostedt
2015-12-17  6:48                 ` Zhang, Yanmin

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=566F8871.7070408@linux.intel.com \
    --to=yanmin_zhang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=peiyangx.qiu@intel.com \
    --cc=rostedt@goodmis.org \
    --cc=rusty@rustcorp.com.au \
    /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.