From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752499AbcAFBOq (ORCPT ); Tue, 5 Jan 2016 20:14:46 -0500 Received: from mga14.intel.com ([192.55.52.115]:22007 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751997AbcAFBOp (ORCPT ); Tue, 5 Jan 2016 20:14:45 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,527,1444719600"; d="scan'208";a="854286809" Message-ID: <568C6A82.6090202@linux.intel.com> Date: Wed, 06 Jan 2016 09:14:42 +0800 From: "Zhang, Yanmin" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Steven Rostedt , "Qiu, PeiyangX" CC: Ingo Molnar , Rusty Russell , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/2] module: deal with the failure of complete_formation References: <567CE0A7.80605@intel.com> <567CEA31.1070507@intel.com> <20160105200114.59fbf832@gandalf.local.home> In-Reply-To: <20160105200114.59fbf832@gandalf.local.home> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 2016/1/6 9:01, Steven Rostedt wrote: > On Fri, 25 Dec 2015 15:03:13 +0800 > "Qiu, PeiyangX" wrote: > >> From: Qiu Peiyang >> >> complete_formation might fail. kernel need clean up >> ftrace records of the module. >> >> The patch fixes it by tuning the operation sequence in >> complete_formation. After complete_formation checks >> verify_export_symbols, call ftrace_module_init to init >> ftrace records. >> >> Signed-off-by: Qiu Peiyang >> Signed-off-by: Zhang Yanmin >> --- >> kernel/module.c | 9 +++++---- >> 1 file changed, 5 insertions(+), 4 deletions(-) >> >> diff --git a/kernel/module.c b/kernel/module.c >> index 8f051a1..0a67c4e 100644 >> --- a/kernel/module.c >> +++ b/kernel/module.c >> @@ -3373,6 +3373,11 @@ 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); >> >> + mutex_unlock(&module_mutex); >> + > First of all, this is buggy. You can't just move the locking of > module_mutex. That is needed to modify mod->state. > > Second of all, you are solving this wrong. I guess we should add > ftrace_module_init_fail() function to cover the cases where the module > can fail before calling do_init_module(), as if that happens it does > not call the module going notifiers. It's a good idea although ftrace_module_init_fail might be complicated. Thanks, Yanmin