From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753760AbbCJRbf (ORCPT ); Tue, 10 Mar 2015 13:31:35 -0400 Received: from mx1.redhat.com ([209.132.183.28]:52069 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753209AbbCJRbb (ORCPT ); Tue, 10 Mar 2015 13:31:31 -0400 Date: Tue, 10 Mar 2015 12:30:49 -0500 From: Josh Poimboeuf To: Petr Mladek Cc: Seth Jennings , Jiri Kosina , Rusty Russell , Miroslav Benes , Masami Hiramatsu , mingo@kernel.org, mathieu.desnoyers@efficios.com, oleg@redhat.com, paulmck@linux.vnet.ibm.com, live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, andi@firstfloor.org, rostedt@goodmis.org, tglx@linutronix.de Subject: Re: [PATCH v3] livepatch/module: Correctly handle coming and going modules Message-ID: <20150310173049.GP10815@treble.redhat.com> References: <1425907528-22976-1-git-send-email-pmladek@suse.cz> <20150309144055.GA10815@treble.redhat.com> <20150310120103.GC1813@dhcp128.suse.cz> <20150310142204.GK10815@treble.redhat.com> <20150310143617.GA3574@dhcp128.suse.cz> <20150310144701.GL10815@treble.redhat.com> <20150310165802.GC3574@dhcp128.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150310165802.GC3574@dhcp128.suse.cz> User-Agent: Mutt/1.5.23.1-rc1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 10, 2015 at 05:58:02PM +0100, Petr Mladek wrote: > On Tue 2015-03-10 09:47:01, Josh Poimboeuf wrote: > > On Tue, Mar 10, 2015 at 03:36:17PM +0100, Petr Mladek wrote: > > > On Tue 2015-03-10 09:22:04, Josh Poimboeuf wrote: > > > > On Tue, Mar 10, 2015 at 01:01:07PM +0100, Petr Mladek wrote: > > > > > On Mon 2015-03-09 09:40:55, Josh Poimboeuf wrote: > > > > > > On Mon, Mar 09, 2015 at 02:25:28PM +0100, Petr Mladek wrote: > > > > > > > diff --git a/kernel/module.c b/kernel/module.c > > > > > > > index d856e96a3cce..b3ffc231ce0d 100644 > > > > > > > --- a/kernel/module.c > > > > > > > +++ b/kernel/module.c > > > > > > > @@ -3271,6 +3271,10 @@ static int load_module(struct load_info *info, const char __user *uargs, > > > > > > > } > > > > > > > #endif > > > > > > > > > > > > > > +#ifdef CONFIG_LIVEPATCH > > > > > > > + mod->klp_alive = false; > > > > > > > +#endif > > > > > > > + > > > > > > > > > > > > I don't think you need this initialization. It looks like the module > > > > > > struct is embedded in the mod->module_core region which is initialized > > > > > > to zero in move_module(). > > > > > > > > > > I have looked at this before but I was not able to find a code > > > > > zeroing struct module. If I get it correctly, mod->module_core > > > > > is a location where symbol table sections are copied or so. > > > > > > > > Yeah, it's far from obvious. AFAICT, it's cleared by the > > > > "memset(ptr, 0, mod->core_size)" line. > > > > > > What I wanted to say is that module_core is not struct module. It > > > seems that it points to the module code. See within_module_core() and > > > how it is used(). > > > > > > By other words, I think that struct module is not zeroed and we need > > > to initialize the bool. > > > > > > Or did I miss anything? > > > > My understanding is that module_core is not only code. It also contains the > > struct module itself. Verified in crash: > > > > crash> mod |head -n2 > > MODULE NAME SIZE OBJECT FILE > > ffffffffa0003180 video 19905 (not loaded) [CONFIG_KALLSYMS] > > crash> module.module_core,core_size 0xffffffffa0003180 > > module_core = 0xffffffffa0000000 > > core_size = 0x4dc1 > > OK, you are right that struct module is inside mod->module_core. But I > am still not convinced that the structure is zeroed. > > There are the following commands in move_module() > > ptr = module_alloc_update_bounds(mod->core_size); > [...] > memset(ptr, 0, mod->core_size); > mod->module_core = ptr; > > if (mod->init_size) { > [...] > } else > mod->module_init = NULL; > > > The needed memory is allocated and zeroed but the pointer > is written to the temporary place. > > I do not see any code that would copy parts of struct module from the > temporary place to the newly allocated one. It seems that the whole > structure is copied. > > Huh, the code is really twisted but I think that the space for the > temporary structure is not zeroed. One week proof is that the code > does mod->module_init = NULL; It would not make sense if the > temporary location was zeroed. > > > Of course, I will be happy if anyone convince me that I am wrong and > we could omit the initialization. Ok, I didn't realize the struct module was copied as part of the elf section copy logic. I think we're getting close now :-) >>From a generated mod.C file: __visible struct module __this_module __attribute__((section(".gnu.linkonce.this_module"))) = { .name = KBUILD_MODNAME, .init = init_module, #ifdef CONFIG_MODULE_UNLOAD .exit = cleanup_module, #endif .arch = MODULE_ARCH_INIT, }; The struct is statically initialized as a global variable in the module. So the elements not specified in the static initializer should all be cleared to zero by the compiler. -- Josh