Received: by 10.223.176.46 with SMTP id f43csp1179983wra; Fri, 19 Jan 2018 08:00:08 -0800 (PST) X-Google-Smtp-Source: ACJfBouC4jEix6+YsF+lOrPxw+t0SiVOaYegxMdUSzSJ6++BHs6pVZMYWn8iJxA0Z5EsfhIWIG6Z X-Received: by 2002:a17:902:d217:: with SMTP id t23-v6mr1859076ply.303.1516377608704; Fri, 19 Jan 2018 08:00:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516377608; cv=none; d=google.com; s=arc-20160816; b=DoWgW9m2MWbrlWuYv86bwnzQB69O9fcGUQ2buzUlnAViJjuSJJBLpEJkCtEQtU4eCm +qnWjk7XCKC260LUaLi5XWXCEOKVw9bDfSWqg5CMp36o7/FRAb0OBJ27IIOCypYgl31H 3JvabVXGZVntQSGMG8pd5YQ7c+6XxkYmJlnl12NYvBi1pnHyF8jNhZvgCc3+G5WppzQ9 8nH9f2PvsUEsqMrRYL9GP9qUyomjrE5plSsThzcXZQImweT0IF+qypxvVpctUQudOGv1 crBhpupgZXDH4AA+KHWGbqVr/O8He5A5RlqbNnLWVNxo33q3wxshMTMjW436prcgr7Mr 5DpA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=TN3O2o2unfZWXrQoy9VErQ645i1EoRPup1xU3aOIycs=; b=XqCl+jhQERMEVGaVLPwxOOnXYQ3uism4TOASl7AAlmQ6iApE8NOvn6BlwA6+6YDBEX aiK213SCkF91M0EJpPN3f5eBoZ5kLUfihuSpUi5gD2ISORKd6f8LZD7/r2d1QIHFUZxp bL5ugJzBqRRpvNaEaeHj22wU1N8HfH52sCsrCL8h60lhAJ4+NshhmwlCscwLC5VCOjpK EoArc2ls9p833S78IrVh4QGCm5WRV4M9I1vt+c5nV2ylfI+qiDajc6qzkcOM4iqIm3Kv p5LxcETtU87bKYPatuJtME9jhrbU+YFrVEIOOa2tw8FFcJmMENVYgmULNDgq1FgmivG/ v5iw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l1-v6si923435plg.56.2018.01.19.07.59.46; Fri, 19 Jan 2018 08:00:08 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756119AbeASP7G (ORCPT + 99 others); Fri, 19 Jan 2018 10:59:06 -0500 Received: from mx2.suse.de ([195.135.220.15]:47940 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755702AbeASP7A (ORCPT ); Fri, 19 Jan 2018 10:59:00 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 0761EAE28; Fri, 19 Jan 2018 15:58:59 +0000 (UTC) Date: Fri, 19 Jan 2018 16:58:58 +0100 From: Petr Mladek To: Jason Baron Cc: linux-kernel@vger.kernel.org, live-patching@vger.kernel.org, jpoimboe@redhat.com, jeyu@kernel.org, jikos@kernel.org, mbenes@suse.cz Subject: Re: [PATCH v5 0/3] livepatch: introduce atomic replace Message-ID: <20180119155858.2644col4z2uejxs2@pathway.suse.cz> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170421 (1.8.2) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri 2018-01-12 14:55:13, Jason Baron wrote: > Hi, > > While using livepatch, I found that when doing cumulative patches, if a patched > function is completed reverted by a subsequent patch (back to its original state) > livepatch does not revert the funtion to its original state. Specifically, if > patch A introduces a change to function 1, and patch B reverts the change to > function 1 and introduces changes to say function 2 and 3 as well, the change > that patch A introduced to function 1 is still present. This could be addressed > by first completely removing patch A (disable and then rmmod) and then inserting > patch B (insmod and enable), but this leaves an unpatched window. In discussing > this issue with Josh on the kpatch mailing list, he mentioned that we could get > 'atomic replace working properly', and that is the direction of this patchset: > https://www.redhat.com/archives/kpatch/2017-June/msg00005.html JFYI, I have spent a lot of time reviewing the patchset this week. IMHO, it is basically correct. I am just not happy with the design, namely code symmetry, code duplication, and the way how "dynamic" and "nop" terms are used. I have started to play with the code. Otherwise, it was pretty hard to be sure if another design would work. I think that I have something useful. But it still need some testing and clean up. I believe that I would be able to send it next week. Best Regards, Petr PS: Jason, you did a great job. Do not worry. I will keep you as the author of the patches even when I send an updated version.