Message ID | 20221026194122.11761-1-mpdesouza@suse.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp453135wru; Wed, 26 Oct 2022 12:43:57 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5UpKz5WFvlrysePrzqWNLlMmFmilC8vXB3UhJcbcc7VfNySCG+9d0j5HBfjrg1vKruuOvs X-Received: by 2002:a17:90b:264d:b0:20d:3935:778 with SMTP id pa13-20020a17090b264d00b0020d39350778mr5827134pjb.64.1666813437627; Wed, 26 Oct 2022 12:43:57 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666813437; cv=none; d=google.com; s=arc-20160816; b=AdQERf5wR3+FCDuxuTehAVNY/uOZDFLeLGCmdt0wFEGOtw/heb1/NF2zCymAr8rcwr nSG3+MP9hVtpPNtft+7eaLyQJ+tUjIAPh1+upojI7aClWc3RaCnhnTQyZ4MLbeXE7H1I HyKinRrWUrblMxiQHO+l0gcb3c+vKAC8Ycmkf16svWLTPIBfZOlrvHltXPWNhKv5t8pE e9tahGFZLm5eFXafprNzqeP/pXs0cWQvFDWZNnVebZrA+5cS9JdybCfHm1lT9La9EHAH c144qtJY1Cxp0cgubcorW8dGlTUMWdJ77Ms6bs74jWApa9pxxKZNXpqz4EJUfyRaDwbc M1cQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=IeeQlPhUw/2ROpMbMT/QHc9rakMBnDEvhQyjwBHr2gw=; b=ycs8qi6IT844Ln3IYSVZ2F5XSr1TlMAUwCXgFhX3XtC0Pkddrbme9o3i7d7k1Q1jOJ CKkzKsxHIasIFFHBeUZ9fL7LVX/IfIuJUYsE7+uEqAx1VQnuoW1YfjiL9BekYhVpEsY6 O9CeqLeT3jfnHU8Af9ygerI9xPjROYTqXI67PKCgo2BdWLXQWpf4pmyw7sm/PByGHqca 6g2nD5Zqw9b2s8TWfCkIcpItCu857c1lj0zAX91Q7v2iKB2DMqe7w3gFTdYoHERbVTkK q66mMljC49kmVr66rq4mpaUX+k38bzfW3D/tmkdpYOJ21cdsJjN3/VLvz7Y7QHoA15Zi THjg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=CTNUecuQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d10-20020a63734a000000b0046f33e40222si6277095pgn.669.2022.10.26.12.43.43; Wed, 26 Oct 2022 12:43:57 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@suse.com header.s=susede1 header.b=CTNUecuQ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=QUARANTINE sp=QUARANTINE dis=NONE) header.from=suse.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234235AbiJZTlq (ORCPT <rfc822;pwkd43@gmail.com> + 99 others); Wed, 26 Oct 2022 15:41:46 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:38342 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234994AbiJZTlh (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 26 Oct 2022 15:41:37 -0400 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C94E1BA908; Wed, 26 Oct 2022 12:41:36 -0700 (PDT) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 3BCC321FFC; Wed, 26 Oct 2022 19:41:35 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1666813295; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=IeeQlPhUw/2ROpMbMT/QHc9rakMBnDEvhQyjwBHr2gw=; b=CTNUecuQRTd5R0V8FdqFMQ660QjmXQMAIISAE3hTUaCrKofc27TvkYFpjIrphBDVryTqIS 1WrFt+oSPrvntwGT2bC/sIOsEJ+/LSsQyhqQrIRaO2J2OPtqIHj0k/IpMCuEwyLNJH2uQu 5EbVwMgXyYY6ZXydgzOl75yspyOAj0g= Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id B17D313A77; Wed, 26 Oct 2022 19:41:32 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id 7AicGmyNWWNlFwAAMHmgww (envelope-from <mpdesouza@suse.com>); Wed, 26 Oct 2022 19:41:32 +0000 From: Marcos Paulo de Souza <mpdesouza@suse.com> To: linux-kernel@vger.kernel.org, live-patching@vger.kernel.org Cc: jpoimboe@redhat.com, joe.lawrence@redhat.com, pmladek@suse.com, Marcos Paulo de Souza <mpdesouza@suse.com> Subject: [PATCH v2 0/4] livepatch: Add garbage collection for shadow variables Date: Wed, 26 Oct 2022 16:41:18 -0300 Message-Id: <20221026194122.11761-1-mpdesouza@suse.com> X-Mailer: git-send-email 2.37.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_MED,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747780567219854138?= X-GMAIL-MSGID: =?utf-8?q?1747780567219854138?= |
Series |
livepatch: Add garbage collection for shadow variables
|
|
Message
Marcos Paulo de Souza
Oct. 26, 2022, 7:41 p.m. UTC
Hello, This is the v2 of the livepatch shadow GC patches. The changes are minor since nobody asked for for big code changes. Changes from v1: * Reworked commit messages (Petr) * Added my SoB which was missing in some patches, or the ordering was wrong. (Josh) * Change __klp_shadow_get_or_use to __klp_shadow_get_or_add_locked and add a comment (Petr) * Add lockdep_assert_held on __klp_shadow_get_or_add_locked (Petr) about it's meaning (Petr) * CCing LKML (Josh) Some observations: * Petr has reviewed some of the patches that we created. I kept the Reviewed-by tags since he wrote the patches some time ago and now he reviewed them again on the ML. * There were questions about possible problems about using klp_shadow_types instead of using ids, but Petr already explained that internally it still uses the id to find the correct livepatch. * Regarding the possibility of multiple patches use the same ID, the problem already existed before. Petr suggested using a "stringified" version using name and id, but nobody has commented yet. I can implement such feature in a v3 if necessary. Marcos Paulo de Souza (2): livepatch/shadow: Introduce klp_shadow_type structure livepatch/shadow: Add garbage collection of shadow variables Petr Mladek (2): livepatch/shadow: Separate code to get or use pre-allocated shadow variable livepatch/shadow: Separate code removing all shadow variables for a given id include/linux/livepatch.h | 50 ++- kernel/livepatch/core.c | 39 +++ kernel/livepatch/core.h | 1 + kernel/livepatch/shadow.c | 297 +++++++++++++----- kernel/livepatch/transition.c | 4 +- lib/livepatch/test_klp_shadow_vars.c | 119 ++++--- samples/livepatch/livepatch-shadow-fix1.c | 24 +- samples/livepatch/livepatch-shadow-fix2.c | 34 +- .../selftests/livepatch/test-shadow-vars.sh | 2 +- 9 files changed, 417 insertions(+), 153 deletions(-)
Comments
On Wed 2022-10-26 16:41:18, Marcos Paulo de Souza wrote: > Hello, > > This is the v2 of the livepatch shadow GC patches. The changes are minor since > nobody asked for for big code changes. > > Changes from v1: > * Reworked commit messages (Petr) > * Added my SoB which was missing in some patches, or the ordering was wrong. (Josh) > * Change __klp_shadow_get_or_use to __klp_shadow_get_or_add_locked and add a comment (Petr) > * Add lockdep_assert_held on __klp_shadow_get_or_add_locked (Petr) > about it's meaning (Petr) > * CCing LKML (Josh) > > Some observations: > * Petr has reviewed some of the patches that we created. I kept the Reviewed-by > tags since he wrote the patches some time ago and now he reviewed them again > on the ML. > * There were questions about possible problems about using klp_shadow_types > instead of using ids, but Petr already explained that internally it still uses > the id to find the correct livepatch. > * Regarding the possibility of multiple patches use the same ID, the problem > already existed before. Petr suggested using a "stringified" version using > name and id, but nobody has commented yet. I can implement such feature in a > v3 if necessary. > > Marcos Paulo de Souza (2): > livepatch/shadow: Introduce klp_shadow_type structure > livepatch/shadow: Add garbage collection of shadow variables > > Petr Mladek (2): > livepatch/shadow: Separate code to get or use pre-allocated shadow > variable > livepatch/shadow: Separate code removing all shadow variables for a > given id From my POV, the patchset is ready for pushing upstream. Well, we need to get approval from kpatch-build users. Joe described possible problems in replay for v3, see https://lore.kernel.org/r/b5fc2891-2fb0-4aa7-01dd-861da22bb7ea@redhat.com Best Regards, Petr
On Tue, Nov 01, 2022 at 11:43:50AM +0100, Petr Mladek wrote: > On Wed 2022-10-26 16:41:18, Marcos Paulo de Souza wrote: > > Hello, > > > > This is the v2 of the livepatch shadow GC patches. The changes are minor since > > nobody asked for for big code changes. > > > > Changes from v1: > > * Reworked commit messages (Petr) > > * Added my SoB which was missing in some patches, or the ordering was wrong. (Josh) > > * Change __klp_shadow_get_or_use to __klp_shadow_get_or_add_locked and add a comment (Petr) > > * Add lockdep_assert_held on __klp_shadow_get_or_add_locked (Petr) > > about it's meaning (Petr) > > * CCing LKML (Josh) > > > > Some observations: > > * Petr has reviewed some of the patches that we created. I kept the Reviewed-by > > tags since he wrote the patches some time ago and now he reviewed them again > > on the ML. > > * There were questions about possible problems about using klp_shadow_types > > instead of using ids, but Petr already explained that internally it still uses > > the id to find the correct livepatch. > > * Regarding the possibility of multiple patches use the same ID, the problem > > already existed before. Petr suggested using a "stringified" version using > > name and id, but nobody has commented yet. I can implement such feature in a > > v3 if necessary. > > > > Marcos Paulo de Souza (2): > > livepatch/shadow: Introduce klp_shadow_type structure > > livepatch/shadow: Add garbage collection of shadow variables > > > > Petr Mladek (2): > > livepatch/shadow: Separate code to get or use pre-allocated shadow > > variable > > livepatch/shadow: Separate code removing all shadow variables for a > > given id > > From my POV, the patchset is ready for pushing upstream. Petr, what do you think about merging the first two patches, since they just cleanups and simplifications? > > Well, we need to get approval from kpatch-build users. Joe described > possible problems in replay for v3, see > https://lore.kernel.org/r/b5fc2891-2fb0-4aa7-01dd-861da22bb7ea@redhat.com > > Best Regards, > Petr
On Mon 2023-01-23 14:33:31, Marcos Paulo de Souza wrote: > On Tue, Nov 01, 2022 at 11:43:50AM +0100, Petr Mladek wrote: > > On Wed 2022-10-26 16:41:18, Marcos Paulo de Souza wrote: > > > Hello, > > > > > > This is the v2 of the livepatch shadow GC patches. The changes are minor since > > > nobody asked for for big code changes. > > > > > > Changes from v1: > > > * Reworked commit messages (Petr) > > > * Added my SoB which was missing in some patches, or the ordering was wrong. (Josh) > > > * Change __klp_shadow_get_or_use to __klp_shadow_get_or_add_locked and add a comment (Petr) > > > * Add lockdep_assert_held on __klp_shadow_get_or_add_locked (Petr) > > > about it's meaning (Petr) > > > * CCing LKML (Josh) > > > > > > Some observations: > > > * Petr has reviewed some of the patches that we created. I kept the Reviewed-by > > > tags since he wrote the patches some time ago and now he reviewed them again > > > on the ML. > > > * There were questions about possible problems about using klp_shadow_types > > > instead of using ids, but Petr already explained that internally it still uses > > > the id to find the correct livepatch. > > > * Regarding the possibility of multiple patches use the same ID, the problem > > > already existed before. Petr suggested using a "stringified" version using > > > name and id, but nobody has commented yet. I can implement such feature in a > > > v3 if necessary. > > > > > > Marcos Paulo de Souza (2): > > > livepatch/shadow: Introduce klp_shadow_type structure > > > livepatch/shadow: Add garbage collection of shadow variables > > > > > > Petr Mladek (2): > > > livepatch/shadow: Separate code to get or use pre-allocated shadow > > > variable > > > livepatch/shadow: Separate code removing all shadow variables for a > > > given id > > > > From my POV, the patchset is ready for pushing upstream. > > Petr, what do you think about merging the first two patches, since they just > cleanups and simplifications? Sounds reasonable to me. I am going to push them by the end of the week if nobody complained in the meantime. Best Regards, Petr
On Tue 2023-01-24 16:51:08, Petr Mladek wrote: > On Mon 2023-01-23 14:33:31, Marcos Paulo de Souza wrote: > > On Tue, Nov 01, 2022 at 11:43:50AM +0100, Petr Mladek wrote: > > > On Wed 2022-10-26 16:41:18, Marcos Paulo de Souza wrote: > > > > Hello, > > > > > > > > This is the v2 of the livepatch shadow GC patches. The changes are minor since > > > > nobody asked for for big code changes. > > > > > > > > Changes from v1: > > > > * Reworked commit messages (Petr) > > > > * Added my SoB which was missing in some patches, or the ordering was wrong. (Josh) > > > > * Change __klp_shadow_get_or_use to __klp_shadow_get_or_add_locked and add a comment (Petr) > > > > * Add lockdep_assert_held on __klp_shadow_get_or_add_locked (Petr) > > > > about it's meaning (Petr) > > > > * CCing LKML (Josh) > > > > > > > > Some observations: > > > > * Petr has reviewed some of the patches that we created. I kept the Reviewed-by > > > > tags since he wrote the patches some time ago and now he reviewed them again > > > > on the ML. > > > > * There were questions about possible problems about using klp_shadow_types > > > > instead of using ids, but Petr already explained that internally it still uses > > > > the id to find the correct livepatch. > > > > * Regarding the possibility of multiple patches use the same ID, the problem > > > > already existed before. Petr suggested using a "stringified" version using > > > > name and id, but nobody has commented yet. I can implement such feature in a > > > > v3 if necessary. > > > > > > > > Marcos Paulo de Souza (2): > > > > livepatch/shadow: Introduce klp_shadow_type structure > > > > livepatch/shadow: Add garbage collection of shadow variables > > > > > > > > Petr Mladek (2): > > > > livepatch/shadow: Separate code to get or use pre-allocated shadow > > > > variable > > > > livepatch/shadow: Separate code removing all shadow variables for a > > > > given id > > > > > > From my POV, the patchset is ready for pushing upstream. > > > > Petr, what do you think about merging the first two patches, since they just > > cleanups and simplifications? > > Sounds reasonable to me. I am going to push them by the end of the > week if nobody complained in the meantime. Josh accepted the idea in the end so we could actually push the entire patchset. I am not sure if anyone else would like to review it so I going to wait a bit longer. Resume: I am going to push the entire patchset the following week (Wednesday?) unless anyone asks for more time or finds a problem. Best Regards, Petr
On 1/26/23 11:35, Petr Mladek wrote: > > Josh accepted the idea in the end so we could actually push the entire > patchset. I am not sure if anyone else would like to review it > so I going to wait a bit longer. > > Resume: > > I am going to push the entire patchset the following week (Wednesday?) > unless anyone asks for more time or finds a problem. > Hi Petr, Re docs: patches (3) and (4) change the klp_shadow_* API. There should be updates (and possibly examples) to Documentation/livepatch/shadow-vars.rst. Having this for v1/v2 would have made review a lot easier, though I understand not wanting to waste cycles on documenting dead ends.
On Thu, Jan 26, 2023 at 12:05:02PM -0500, Joe Lawrence wrote: > On 1/26/23 11:35, Petr Mladek wrote: > > > > Josh accepted the idea in the end so we could actually push the entire > > patchset. I am not sure if anyone else would like to review it > > so I going to wait a bit longer. > > > > Resume: > > > > I am going to push the entire patchset the following week (Wednesday?) > > unless anyone asks for more time or finds a problem. > > > > Hi Petr, > > Re docs: patches (3) and (4) change the klp_shadow_* API. There should > be updates (and possibly examples) to > Documentation/livepatch/shadow-vars.rst. Agreed, a documentation update is definitely needed. Also, as I mentioned, we need to document the motivation behind the change and the expected use cases. Either in the commit log or the documentation, or even better, some combination. There was some very useful background from Nicolai and some very helpful clarifications from Petr. We should make sure all that doesn't get lost in depths of the mailing list. And, while I did finally accept the idea, I still need to do a more in-depth review of the patches. Patches 1-2 look fine, but please give me some time to properly review patches 3 & 4.
On Thu 2023-01-26 10:30:05, Josh Poimboeuf wrote: > On Thu, Jan 26, 2023 at 12:05:02PM -0500, Joe Lawrence wrote: > > On 1/26/23 11:35, Petr Mladek wrote: > > > > > > Josh accepted the idea in the end so we could actually push the entire > > > patchset. I am not sure if anyone else would like to review it > > > so I going to wait a bit longer. > > > > > > Resume: > > > > > > I am going to push the entire patchset the following week (Wednesday?) > > > unless anyone asks for more time or finds a problem. > > > > > > > Hi Petr, > > > > Re docs: patches (3) and (4) change the klp_shadow_* API. There should > > be updates (and possibly examples) to > > Documentation/livepatch/shadow-vars.rst. > > Agreed, a documentation update is definitely needed. > > Also, as I mentioned, we need to document the motivation behind the > change and the expected use cases. Either in the commit log or the > documentation, or even better, some combination. There was some very > useful background from Nicolai and some very helpful clarifications from > Petr. We should make sure all that doesn't get lost in depths of the > mailing list. Great point. I have completely forgot about it. And did not catch the request when quickly scaning the older replies yesterday. > And, while I did finally accept the idea, I still need to do a more > in-depth review of the patches. Patches 1-2 look fine, but please give > me some time to properly review patches 3 & 4. Sure. It is great that the code will get another review! I am going to wait for v3 with updated documentation and review. Best Regards, Petr
On Thu, Jan 26, 2023 at 12:05:02PM -0500, Joe Lawrence wrote: > On 1/26/23 11:35, Petr Mladek wrote: > > > > Josh accepted the idea in the end so we could actually push the entire > > patchset. I am not sure if anyone else would like to review it > > so I going to wait a bit longer. > > > > Resume: > > > > I am going to push the entire patchset the following week (Wednesday?) > > unless anyone asks for more time or finds a problem. > > > > Hi Petr, > > Re docs: patches (3) and (4) change the klp_shadow_* API. There should > be updates (and possibly examples) to > Documentation/livepatch/shadow-vars.rst. I forgot about shadow-vars.rst! This will be added on v3. > > Having this for v1/v2 would have made review a lot easier, though I > understand not wanting to waste cycles on documenting dead ends. That's true. Next time I'll take care of the docs when the API changes. Thanks for the reviews so far! > > -- > Joe >