From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754237AbbCFOzA (ORCPT ); Fri, 6 Mar 2015 09:55:00 -0500 Received: from mx1.redhat.com ([209.132.183.28]:57241 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751101AbbCFOy7 (ORCPT ); Fri, 6 Mar 2015 09:54:59 -0500 Date: Fri, 6 Mar 2015 08:54:23 -0600 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 v2 1/2] livepatch/module: Apply patch when loaded module is unformed Message-ID: <20150306145423.GB488@treble.redhat.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150306140013.GL15177@pathway.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 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. > 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 ;-) -- Josh