From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752770AbdJFWcu (ORCPT ); Fri, 6 Oct 2017 18:32:50 -0400 Received: from mx1.redhat.com ([209.132.183.28]:42546 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751850AbdJFWct (ORCPT ); Fri, 6 Oct 2017 18:32:49 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2C71B5D68B Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=jpoimboe@redhat.com Date: Fri, 6 Oct 2017 17:32:47 -0500 From: Josh Poimboeuf To: Jason Baron Cc: linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, jeyu@kernel.org, jikos@kernel.org, mbenes@suse.cz, pmladek@suse.com Subject: Re: [PATCH v3 2/2] livepatch: add atomic replace Message-ID: <20171006223247.fkkrrtxydq33c7dw@treble> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 06 Oct 2017 22:32:49 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Sep 27, 2017 at 11:41:30PM -0400, Jason Baron wrote: > Since 'atomic replace' has completely replaced all previous livepatch > modules, it explicitly disables all previous livepatch modules. However, > previous livepatch modules that have been replaced, can be re-enabled > if they have the 'replace' flag set. In this case the set of 'nop' > functions is re-calculated, such that it replaces all others. > > For example, if kpatch-a.ko and kpatch-b.ko have the 'replace' flag set > then: > > # insmod kpatch-a.ko > # insmod kpatch-b.ko > > At this point we have: > > # cat /sys/kernel/livepatch/kpatch-a/enabled > 0 > > # cat /sys/kernel/livepatch/kpatch-b/enabled > 1 > > To revert to the kpatch-a state we can do: > > echo 1 > /sys/kernel/livepatch/kpatch-a/enabled > > And now we have: > > # cat /sys/kernel/livepatch/kpatch-a/enabled > 1 > > # cat /sys/kernel/livepatch/kpatch-b/enabled > 0 I don't really like allowing a previously replaced patch to replace the current patch. It's just more unnecessary complexity. If the user wants to atomically revert back to kpatch-a, they should be able to: rmmod kpatch-a insmod kpatch-a.ko > Note that it may be possible to unload (rmmod) replaced patches in some > cases based on the consistency model, when we know that all the functions > that are contained in the patch may no longer be in used, however its > left as future work, if this functionality is desired. If you don't allow a previously replaced patch to be enabled again, I think it would be trivial to let it be unloaded. > Also, __klp_enable_patch() calls klp_add_nops(), which necessitated moving > a bunch of existing functions before __klp_enable_patch(). So there is a > bit of churn in moving functions that are not modified. To make review easier, can you put the moving of functions into a separate patch? -- Josh