From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755190AbbCFPfM (ORCPT ); Fri, 6 Mar 2015 10:35:12 -0500 Received: from cantor2.suse.de ([195.135.220.15]:44710 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754710AbbCFPfI (ORCPT ); Fri, 6 Mar 2015 10:35:08 -0500 Date: Fri, 6 Mar 2015 16:35:49 +0100 From: Petr Mladek To: Josh Poimboeuf 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 v2 1/2] livepatch/module: Apply patch when loaded module is unformed Message-ID: <20150306153548.GO15177@pathway.suse.cz> References: <1425570314-23675-1-git-send-email-pmladek@suse.cz> <1425570314-23675-2-git-send-email-pmladek@suse.cz> <20150305193433.GC1870@treble.redhat.com> <20150306102032.GI15177@pathway.suse.cz> <20150306140013.GL15177@pathway.suse.cz> <20150306145423.GB488@treble.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150306145423.GB488@treble.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 2015-03-06 08:54:23, Josh Poimboeuf wrote: > On Fri, Mar 06, 2015 at 03:00:13PM +0100, Petr Mladek wrote: > > This brings me back to the original idea with that boolean that > > marks the state before and after the coming notifier (module_init). > > We could use a bitfield instead of the two booleans when requested. > > Yeah, that would work. Though I think one boolean is enough? > > For example, just have a mod->klp_live which is initialized to false, > with its value set in the COMING notifier, and cleared in the GOING > notifier. Great optimization. I will use it. > > Alternative solutions: > > > > + reject new patches when a module is coming; this is ugly > > > > + wait with adding new patch until the module leaves the COMING state; > > this might be dangerous or complicated; we would need to leave > > kgr_lock in the middle of the patch registration to avoid a deadlock > > with klp_module_init(); also we might need a waitqueue for each module > > which seems to be even bigger overhead than the two booleans > > > > + always register/enable new patches and fix up the potential mess > > (registered patches order) in klp_module_init(); This is nasty and > > prone to regressions in the future development; > > > > + add another MODULE_STATE where the kallsyms are visible but the > > module is not used yet; this looks to complex; the module states are > > checked on "many" locations > > > > > > I will wait with v3 over the weekend. I hope that it will bring fresh > > mind. Sigh, if I could have slept more with the baby twins. > > Good luck! In my experience, an entire weekend with babies is far from > restful ;-) Yeah, you are right :-) Thanks for review and hint. Best Regards, Petr