From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Petr Mladek <pmladek@suse.cz>
Cc: Seth Jennings <sjenning@redhat.com>,
Jiri Kosina <jkosina@suse.cz>,
Rusty Russell <rusty@rustcorp.com.au>,
Miroslav Benes <mbenes@suse.cz>,
Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
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
Date: Thu, 12 Mar 2015 14:23:03 -0500 [thread overview]
Message-ID: <20150312192303.GA32376@treble.redhat.com> (raw)
In-Reply-To: <1426161313-6474-1-git-send-email-pmladek@suse.cz>
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 <jpoimboe@redhat.com>
next prev parent reply other threads:[~2015-03-12 19:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-12 11:55 [PATCH v4] livepatch/module: Correctly handle coming and going modules Petr Mladek
2015-03-12 19:23 ` Josh Poimboeuf [this message]
2015-03-16 19:15 ` Jiri Kosina
2015-03-17 1:52 ` Rusty Russell
2015-03-17 9:31 ` Jiri Kosina
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150312192303.GA32376@treble.redhat.com \
--to=jpoimboe@redhat.com \
--cc=andi@firstfloor.org \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mbenes@suse.cz \
--cc=mingo@kernel.org \
--cc=oleg@redhat.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=pmladek@suse.cz \
--cc=rostedt@goodmis.org \
--cc=rusty@rustcorp.com.au \
--cc=sjenning@redhat.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.