Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756174AbcC2NFk (ORCPT ); Tue, 29 Mar 2016 09:05:40 -0400 Received: from mx2.suse.de ([195.135.220.15]:38363 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752184AbcC2NFi (ORCPT ); Tue, 29 Mar 2016 09:05:38 -0400 Date: Tue, 29 Mar 2016 15:05:34 +0200 (CEST) From: Jiri Kosina X-X-Sender: jkosina@pobox.suse.cz To: Miroslav Benes cc: Chris J Arges , jeyu@redhat.com, jpoimboe@redhat.com, eugene.shatokhin@rosalab.ru, live-patching@vger.kernel.org, Linux Kernel Mailing List , pmladek@suse.cz Subject: Re: Bug with paravirt ops and livepatches In-Reply-To: Message-ID: References: <20160329120518.GA21252@canonical.com> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1256 Lines: 27 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