Received: by 10.213.65.68 with SMTP id h4csp2658159imn; Mon, 9 Apr 2018 07:05:41 -0700 (PDT) X-Google-Smtp-Source: AIpwx4946Xt5dOV9z9CEhkZir64neCrByvMD1b8pL4deO+WO8jnkdpifGjFOSVC0Hu7v0FAIrzX0 X-Received: by 10.101.72.13 with SMTP id h13mr25078968pgs.420.1523282741635; Mon, 09 Apr 2018 07:05:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1523282741; cv=none; d=google.com; s=arc-20160816; b=gpKvir0HUbj1JZATX/V7OErEke+rQ9M0dwfa3EUS8QND++UWBWbwNRDwFvFlgZUgMJ Pc4A3YlwItUO5aCKJjc65gJmOfFbqIT/Oq6kOj6+N7ZkbzuWKWoza3jP6+VfIvViLTC9 qbILIkUBePLmX1Svs5o3gaV3aijsdvKhEBpaW2JuQyUDPG4iBf1XEpoCMfGscqiqcrEO Q9+nHlTNN0CNztmEBw968u6oNimUGESD+0JfTnhdLmNCFlLCSDYPdnNyoqBpD1ddyKTV YWEp+OAtFcl6xe/YGIDrB34PTFrOpzMLJHkC1AHcoZb1tdHYccqq5LJptw/XaW0e1Ogj Gjzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date :arc-authentication-results; bh=rGdfVbxlMR89XKn+KhbwGlFqAlvF77KUZCk3NQn9RCk=; b=a0VIF6hRNdizYeRwLT0JpSZoFQaUyhUR+u/dO3iyYHXjJt0DcCXfVaGFDizIavazcd GYcaUNtiaE97KEYnma5nKv+o8tOYsG6B/Ik0wy3i+MlgTzCs4G7ZK7svFkgsC/lTh6CP 7+SnInHyKf6gRHS2sw4TqNl+gWpeJJCvZ9KzUjpd5BrJj4IVKeeT9/Ays+qWzmSgXQMF 3tgM3xAhUyH2GkQagc/Y0yAOrvoNqeEiJkBn36xuNuv6swkpGG2TSOKT06hk0JEeeADv ttRh5tsTj1ND0X2S1vX3QUerjvTlW7v6ibBH+2AKu7P4zjqIRrPOm/Ic+VYdyke4M0Zq xgwg== 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 q7si264368pgf.461.2018.04.09.07.05.03; Mon, 09 Apr 2018 07:05:41 -0700 (PDT) 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 S1752052AbeDIOCT (ORCPT + 99 others); Mon, 9 Apr 2018 10:02:19 -0400 Received: from mx2.suse.de ([195.135.220.15]:47724 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751522AbeDIOCR (ORCPT ); Mon, 9 Apr 2018 10:02:17 -0400 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 24960AEA0; Mon, 9 Apr 2018 14:02:16 +0000 (UTC) Date: Mon, 9 Apr 2018 16:02:15 +0200 (CEST) From: Miroslav Benes To: Petr Mladek cc: Jiri Kosina , Josh Poimboeuf , Jason Baron , Joe Lawrence , Jessica Yu , Evgenii Shatokhin , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 4/8] livepatch: Add an extra flag to distinguish registered patches In-Reply-To: <20180323120028.31451-5-pmladek@suse.com> Message-ID: References: <20180323120028.31451-1-pmladek@suse.com> <20180323120028.31451-5-pmladek@suse.com> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 23 Mar 2018, Petr Mladek wrote: > The initial implementation of the atomic replace feature keeps the replaced > patches on the stack. But people would like to remove the replaced patches > from different reasons that will be described in the following patch. > > This patch is just a small preparation step. We will need to keep > the replaced patches registered even when they are not longer on the stack. s/not longer/no longer/ > It is because they are typically unregistered by the module exit script. > > Therefore we need to detect the registered patches another way. "in another way", "differently"? > We could > not use kobj.state_initialized because it is racy. The kobject is destroyed > by an asynchronous call and could not be synchronized using klp_mutex. > > This patch solves the problem by adding a flag into struct klp_patch. > It is manipulated under klp_mutex and therefore it is safe. It is easy > to understand and it is enough in most situations. > > The function klp_is_patch_registered() is not longer needed. Though s/not longer/no longer/ s/Though/So/ ? > it was renamed to klp_is_patch_on_stack() and used in __klp_enable_patch() > as a new sanity check. > > This patch does not change the existing behavior. In my opinion it could be easier for a review to squash the patch into the next one. > Signed-off-by: Petr Mladek > Cc: Josh Poimboeuf > Cc: Jessica Yu > Cc: Jiri Kosina > Cc: Miroslav Benes > Cc: Jason Baron > --- > include/linux/livepatch.h | 2 ++ > kernel/livepatch/core.c | 24 ++++++++++++++++++------ > 2 files changed, 20 insertions(+), 6 deletions(-) > > diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h > index f28af280f9e0..d6e6d8176995 100644 > --- a/include/linux/livepatch.h > +++ b/include/linux/livepatch.h > @@ -150,6 +150,7 @@ struct klp_object { > * @list: list node for global list of registered patches > * @kobj: kobject for sysfs resources > * @obj_list: dynamic list of the object entries > + * @registered: reliable way to check registration status > * @enabled: the patch is enabled (but operation may be incomplete) > * @finish: for waiting till it is safe to remove the patch module > */ > @@ -163,6 +164,7 @@ struct klp_patch { > struct list_head list; > struct kobject kobj; > struct list_head obj_list; > + bool registered; > bool enabled; > struct completion finish; > }; > diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c > index 18c400bd9a33..70c67a834e9a 100644 > --- a/kernel/livepatch/core.c > +++ b/kernel/livepatch/core.c > @@ -45,6 +45,11 @@ > */ > DEFINE_MUTEX(klp_mutex); > > +/* > + * Stack of patches. It defines the order in which the patches can be enabled. > + * Only patches on this stack might be enabled. New patches are added when > + * registered. They are removed when they are unregistered. > + */ > static LIST_HEAD(klp_patches); > > static struct kobject *klp_root_kobj; > @@ -97,7 +102,7 @@ static void klp_find_object_module(struct klp_object *obj) > mutex_unlock(&module_mutex); > } > > -static bool klp_is_patch_registered(struct klp_patch *patch) > +static bool klp_is_patch_on_stack(struct klp_patch *patch) > { > struct klp_patch *mypatch; > > @@ -378,7 +383,7 @@ int klp_disable_patch(struct klp_patch *patch) > > mutex_lock(&klp_mutex); > > - if (!klp_is_patch_registered(patch)) { > + if (!patch->registered) { I don't see any actual problem, but I'd feel safer if we preserve klp_is_patch_on_stack() even somewhere in disable path. Miroslav