Received: by 10.223.185.116 with SMTP id b49csp5555870wrg; Wed, 7 Mar 2018 13:57:12 -0800 (PST) X-Google-Smtp-Source: AG47ELtf4hWTMydvrvCYaQOMz9AdymWqL8Ps9tJx1BtLf8cUWgDo5Az/Pd1gjiFKU77PtdcuZ/dP X-Received: by 10.98.66.89 with SMTP id p86mr23843866pfa.228.1520459832691; Wed, 07 Mar 2018 13:57:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520459832; cv=none; d=google.com; s=arc-20160816; b=Seyu4hFwvUEN2ymTzqOwOa9GlgbNJ9zdnlSFwbK7+stzm7heDJrE/EKEXWwJaZKd/b 2mHYl5sOF2Ol4weZKgzgl59aJJVt8wbac7dFOZ1LRkJe/ll1lNVKpVfqOnoqsGKPg4tm tssVbtTyKDm1JoEXjfyf04C+rVZgm4DIUAaAZ7331KvErnCBLHVmXumfVn5gTHnsfNtv flHOvXIDVV1P6twctOVGdUAZ8t5gi+fl3HUf7+v4hvsME0z9cg0XUbbZhTkNYTjSh5QZ xWN6wJ1YOjQQnozzEHMltCfkIg51HKup2xawPUa9sBQDIQlKKl2QLRxfKf+Bdb7AJsCP GY3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:organization:from:references:cc:to:subject :arc-authentication-results; bh=yTkv8BFtPZ2271zpADWEN2AOKpibxoGBlPnaURTzUH4=; b=Ggpml5Gifu3NE7t03JkyMN8s0D8TSyRRMQ57F110LTVBoohGrC/Bot6ihKjgcy/zat gHsPQpe1dOA6eCLWXZFD9/IFxAhpOuI/Hh6XxMGgn6Ql4MVYMcQMJZQBDhXPtgy7gAuJ zFCX2blz1uuLPdQrPlOgNpjFGXGnwgrI4j2f1t/2aqXzqxdDfo+QmT7d3iOPjPyDgwAD T5IPfHha9lAfhda+Wq0DbCfVJgN2iM0TnNEHhr2uo8K2jcvB1lEwP49MWLNerNPwb3Es UWN+rAidx9YhxZk73hlZg+An929oSIDktBZTa7zsm3ZdlUgDKm6gZwQQ1NObUhJ0KhI+ Vbfw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j9-v6si13496176pll.326.2018.03.07.13.56.58; Wed, 07 Mar 2018 13:57:12 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934059AbeCGVz5 (ORCPT + 99 others); Wed, 7 Mar 2018 16:55:57 -0500 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:50322 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933415AbeCGVzz (ORCPT ); Wed, 7 Mar 2018 16:55:55 -0500 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CFC06404084A; Wed, 7 Mar 2018 21:55:54 +0000 (UTC) Received: from jlaw-desktop.bos.csb (ovpn-123-51.rdu2.redhat.com [10.10.123.51]) by smtp.corp.redhat.com (Postfix) with ESMTP id B87DE215CDA7; Wed, 7 Mar 2018 21:55:53 +0000 (UTC) Subject: Re: [PATCH v10 00/10] livepatch: Atomic replace feature To: Petr Mladek , Jiri Kosina , Josh Poimboeuf , Miroslav Benes Cc: Jason Baron , Jessica Yu , Evgenii Shatokhin , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org References: <20180307082039.10196-1-pmladek@suse.com> From: Joe Lawrence Organization: Red Hat Message-ID: <45877626-2d41-4af8-a8ff-5897585122ad@redhat.com> Date: Wed, 7 Mar 2018 16:55:53 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0 MIME-Version: 1.0 In-Reply-To: <20180307082039.10196-1-pmladek@suse.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 07 Mar 2018 21:55:54 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 07 Mar 2018 21:55:54 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'joe.lawrence@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/07/2018 03:20 AM, Petr Mladek wrote: > The atomic replace allows to create cumulative patches. They > are useful when you maintain many livepatches and want to remove > one that is lower on the stack. In addition it is very useful when > more patches touch the same function and there are dependencies > between them. > > > Changes against v9: > > + Fixed check of valid NOPs for already loaded objects, > regression introduced in v9 [Joe, Mirek] > + Allow to replace even disabled patches [Evgenii] > > Changes against v8: > > + Fixed handling of statically defined struct klp_object > with empty array of functions [Joe, Mirek] > + Removed redundant func->new_func assignment for NOPs [Mirek] > + Improved some wording [Mirek] > > [ ... snip ... ] Hi Petr, I tried updating the test cases I was adding in "[PATCH v0 0/3] additional cumulative livepatch doc/samples" and although one of the cases is better than before, I'm running into a new issue: an expected pre-unpatch callback is not executed (its obj->patched is false). Here's the updated test case: Test 11 ------- - load livepatch - load second livepatch (atomic replace) <- callbacks ok - disable second livepatch <- pre-unpatch skipped - unload livepatch - unload second livepatch % insmod samples/livepatch/livepatch-callbacks-demo.ko [ 2306.806046] livepatch: enabling patch 'livepatch_callbacks_demo' [ 2306.806048] livepatch: 'livepatch_callbacks_demo': initializing patching transition [ 2306.806083] livepatch_callbacks_demo: pre_patch_callback: vmlinux [ 2306.806083] livepatch: 'livepatch_callbacks_demo': starting patching transition [ 2307.743170] livepatch: 'livepatch_callbacks_demo': completing patching transition [ 2307.743317] livepatch_callbacks_demo: post_patch_callback: vmlinux [ 2307.743319] livepatch: 'livepatch_callbacks_demo': patching complet % insmod samples/livepatch/livepatch-callbacks-demo2.ko replace=1 [ 2316.161804] livepatch: enabling patch 'livepatch_callbacks_demo2' [ 2316.161807] livepatch: 'livepatch_callbacks_demo2': initializing patching transition [ 2316.161842] livepatch_callbacks_demo2: pre_patch_callback: vmlinux [ 2316.161843] livepatch: 'livepatch_callbacks_demo2': starting patching transition [ 2317.727141] livepatch: 'livepatch_callbacks_demo2': completing patching transition [ 2317.727254] livepatch_callbacks_demo2: post_patch_callback: vmlinux [ 2317.727255] livepatch: 'livepatch_callbacks_demo2': patching complete % echo 0 > /sys/kernel/livepatch/livepatch_callbacks_demo2/enabled [ 2328.995854] livepatch: 'livepatch_callbacks_demo2': initializing unpatching transition [ 2328.995898] livepatch: 'livepatch_callbacks_demo2': starting unpatching transition [ 2330.719234] livepatch: 'livepatch_callbacks_demo2': completing unpatching transition [ 2330.719597] livepatch_callbacks_demo2: post_unpatch_callback: vmlinux [ 2330.719599] livepatch: 'livepatch_callbacks_demo2': unpatching complete % rmmod samples/livepatch/livepatch-callbacks-demo2.ko % rmmod samples/livepatch/livepatch-callbacks-demo.ko Running against v10, callbacks seem to be good up until I disable an atomic replace patch. My understanding is that the original patch's unpatch callbacks should be skipped (as they were). I was surprised to see that atomic replacement patch only ran it's post-unpatch callback. Unfortunately I'm running out of time to further debug today, but thought I would share these results. I can dig in more tomorrow. Regards, -- Joe