From: Petr Mladek <pmladek@suse.cz>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Seth Jennings <sjenning@redhat.com>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Jiri Kosina <jkosina@suse.cz>, 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 v2 2/2] livepatch/module: Correctly handle going modules
Date: Mon, 9 Mar 2015 10:16:56 +0100 [thread overview]
Message-ID: <20150309091656.GF9162@pathway.suse.cz> (raw)
In-Reply-To: <87a8zpy5wb.fsf@rustcorp.com.au>
On Sat 2015-03-07 11:34:36, Rusty Russell wrote:
> Petr Mladek <pmladek@suse.cz> writes:
> > Existing live patches are removed from going modules using a notify handler.
> > There are two problems with the current implementation.
> >
> > First, 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.
> >
> > Second, if we start supporting patches with semantic changes between function
> > calls, we would need to apply any new patch even for going modules. Note that
> > the code from the module could be called even in the GOING state until
> > mod->exit() finishes. See below for example.
>
> I don't think you should handle going modules at all. Rarely happens,
> and it should happen fast.
I would like to handle it correctly. It would be pity to break a system
just because of a module removal. Also the extra overhead will be
very small and it will happen only very rarely.
We will apply one new patch and remove it quickly after that. But this
will happen only when a module is removed and a patch is added at at
the "same" time.
> If you can hold the module_lock, the easiest thing to do is have us wake
> module_wq when a module is freed, then you can just:
Unfortunately, we could not use a waitqueue easily. We would need to
release klp_mutex to do not block going modules. But we could not
do so in the middle of a patch adding.
BTW: It seems that module_wq is used for coming modules. We could not
use it for coming modules from the same reason. In addition, waiters
are weaken after mod->init(). But we would need to apply the patch
before mod->init() to avoid any inconsistency.
Anyway, thanks for feedback.
Best Regards,
Petr
> retry:
> err = wait_event_interruptible(module_wq,
> !modules_unloading());
> if (err)
> goto out;
>
> /* Now re-check under lock. */
> mutex_lock(&module_lock);
> if (unlikely(modules_unloading()) {
> mutex_unlock(&module_lock);
> goto retry;
> }
>
> Cheers,
> Rusty.
>
>
next prev parent reply other threads:[~2015-03-09 9:16 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-05 15:45 [PATCH v2 0/2] livepatch/module: Avoid races between modules and live patches Petr Mladek
2015-03-05 15:45 ` [PATCH v2 1/2] livepatch/module: Apply patch when loaded module is unformed Petr Mladek
2015-03-05 19:34 ` Josh Poimboeuf
2015-03-06 10:20 ` Petr Mladek
2015-03-06 14:00 ` Petr Mladek
2015-03-06 14:54 ` Josh Poimboeuf
2015-03-06 15:35 ` Petr Mladek
2015-03-05 15:45 ` [PATCH v2 2/2] livepatch/module: Correctly handle going modules Petr Mladek
2015-03-05 19:35 ` Josh Poimboeuf
2015-03-07 1:04 ` Rusty Russell
2015-03-09 9:16 ` Petr Mladek [this message]
2015-03-10 2:23 ` Rusty Russell
2015-03-10 11:15 ` Petr Mladek
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=20150309091656.GF9162@pathway.suse.cz \
--to=pmladek@suse.cz \
--cc=andi@firstfloor.org \
--cc=jkosina@suse.cz \
--cc=jpoimboe@redhat.com \
--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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®