[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LNX.2.00.1603291504010.3656@cbobk.fhfr.pm>
Date: Tue, 29 Mar 2016 15:05:34 +0200 (CEST)
From: Jiri Kosina <jikos@...nel.org>
To: Miroslav Benes <mbenes@...e.cz>
cc: Chris J Arges <chris.j.arges@...onical.com>, jeyu@...hat.com,
jpoimboe@...hat.com, eugene.shatokhin@...alab.ru,
live-patching@...r.kernel.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
pmladek@...e.cz
Subject: Re: Bug with paravirt ops and livepatches
On Tue, 29 Mar 2016, Miroslav Benes wrote:
> > 1) Jessica proposed using the Arch-independent patchset ensure that livepatch
> > finishes writing its relas before apply_paravirt() is called. However, this
> > introduces a bit more arch-dependent code. It would be useful to see if other
> > arches are affected by this as well.
>
> I think this is the way to go. Provided we have Jessica's two patch sets
> applied (arch-independent and notifiers removal) there are two options. We
> either move a call to klp_coming_module() somewhere before
> module_finalize(), or we move the problematic parts of module_finalize()
> to the end of load_module() (on x86 it is probably module_finalize() as a
> whole). The former is almost impossible because of the dependencies
> (ftrace and such), the latter should be doable (with very careful check we
> won't break anything).
Agreed; I think we should be safe applying all the alternatives (with
paravirt being really just a special case of those) to the coming module
at the very last phase; they really are required only during runtime, but
nothing else should be depending on them. Right? If anyone is able to come
up with and counter-example, please speak up :)
Thanks,
--
Jiri Kosina
SUSE Labs
Powered by blists - more mailing lists