From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755870AbbCLTXy (ORCPT ); Thu, 12 Mar 2015 15:23:54 -0400 Received: from mx1.redhat.com ([209.132.183.28]:56451 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755849AbbCLTXi (ORCPT ); Thu, 12 Mar 2015 15:23:38 -0400 Date: Thu, 12 Mar 2015 14:23:03 -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 v4] livepatch/module: Correctly handle coming and going modules Message-ID: <20150312192303.GA32376@treble.redhat.com> References: <1426161313-6474-1-git-send-email-pmladek@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1426161313-6474-1-git-send-email-pmladek@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 Thu, Mar 12, 2015 at 12:55:13PM +0100, Petr Mladek wrote: > There is a notifier that handles live patches for coming and going modules. > It takes klp_mutex lock to avoid races with coming and going patches but > it does not keep the lock all the time. Therefore the following races are > possible: > > 1. The notifier is called sometime in STATE_MODULE_COMING. The module > is visible by find_module() in this state all the time. It means that > new patch can be registered and enabled even before the notifier is > called. It might create wrong order of stacked patches, see below > for an example. > > 2. New patch could still see the module in the GOING state even after > the notifier has been called. It will try to initialize the related > object structures but the module could disappear at any time. There > will stay mess in the structures. It might even cause an invalid > memory access. > > This patch solves the problem by adding a boolean variable into struct module. > The value is true after the coming and before the going handler is called. > New patches need to be applied when the value is true and they need to ignore > the module when the value is false. Acked-by: Josh Poimboeuf