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....@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) <rost...@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....@intel.com> >>> Signed-off-by: Zhang Yanmin <yanmin.zh...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
