Received: by 10.223.185.116 with SMTP id b49csp3857042wrg; Tue, 6 Mar 2018 06:12:46 -0800 (PST) X-Google-Smtp-Source: AG47ELu57I0E5CWTIAxfy2Y5ExZxJdgmfHkXyLKW9/wmCJXn74uxNdHsByJ9VgUBfIojrpNMA5bB X-Received: by 2002:a17:902:a607:: with SMTP id u7-v6mr16601622plq.367.1520345566761; Tue, 06 Mar 2018 06:12:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1520345566; cv=none; d=google.com; s=arc-20160816; b=A3BHFitBUckUsYpjb6xolGG/jSmtR4dcc1pENVGEpiEiU2V/Yg75mqu2VZ0hLADrbX GPVyjmVCVJbcEVCXozbEXa8EnJgM0kfJ5BP33mzkHeuooDb7WXi8RZZ/PlFQlh5l61T9 labugZBLz3Aij3+fXu17f+C7xVkuqVcjk40gqUHMw41tNvpo39fzRfY0G7lljCBsxIdu 0gTahBDFldhGx0gURx+AIii8Sm+uRuugvEMxcE3A6ZWAVPlJpbc1dgy84GQCTukX2x8u LaOvto8mp/PpFhWIA2gJC7sJE1TdC/v/yezwxTHReKk0OArPSXrSFtdi+YETf5V3c+8r s36Q== 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=M0XWStuAhSnVdNobku4sv8jY7DHyNXRjdCZuOmt1eOQ=; b=c0FGUyaf6Gtov2xzxyZlbvBxowiHmYB5de0l/tU6JYPuzyLkvZJj6UCXgBMmPKm3VD yKS1LIOxzmp5sesPdFB/e5+vxybZaX0MlNTkOc4NBf0jbqwm83uPidsqOYHGcDtx9+/F RHEQ9ESNl1mh7swXorpliMs74cKI2Pf0cLAG1Uo1Pg4DKSS8xhpo0neAsiL1dShBuFqQ lWbLT+bf8lqtjLVEfKGGyY5E8HJC2qCJcoqLJp9hUB8gGTAAVotFMgw5MucYA02LNsaZ uIkZD0OPE8UUH+gsgH46xYHjkOcsBzZE9rNvdoEPHjmxyZQ4Fp2Mucfr+7eSbFc79ODF zg7Q== 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 t1si9923967pgs.618.2018.03.06.06.12.32; Tue, 06 Mar 2018 06:12:46 -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 S932960AbeCFOKm (ORCPT + 99 others); Tue, 6 Mar 2018 09:10:42 -0500 Received: from mx2.suse.de ([195.135.220.15]:49050 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932147AbeCFOKk (ORCPT ); Tue, 6 Mar 2018 09:10:40 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 28DC7AC71; Tue, 6 Mar 2018 14:10:39 +0000 (UTC) Date: Tue, 6 Mar 2018 15:10:38 +0100 From: Petr Mladek To: Miroslav Benes Cc: Joe Lawrence , Jiri Kosina , Josh Poimboeuf , Jason Baron , Jessica Yu , Evgenii Shatokhin , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v8 7/8] livepatch: Correctly handle atomic replace for not yet loaded modules Message-ID: <20180306141038.v3ufd7llwhwfhosq@pathway.suse.cz> References: <20180221132914.4809-1-pmladek@suse.com> <20180221132914.4809-8-pmladek@suse.com> <20180301102859.zwrt6w36ub474nb2@pathway.suse.cz> <7f920ec3-dfe0-6a4d-dd25-5d5c4fa75714@redhat.com> 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 Mon 2018-03-05 10:54:16, Miroslav Benes wrote: > On Fri, 2 Mar 2018, Joe Lawrence wrote: > > > On 03/01/2018 05:28 AM, Petr Mladek wrote: > > > On Thu 2018-02-22 22:00:28, Miroslav Benes wrote: > > >> On Wed, 21 Feb 2018, Petr Mladek wrote: > > >>> This patch allows the late initialization. > > >>> > > >>> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c > > >>> index ad508a86b2f9..da1438d47d83 100644 > > >>> --- a/kernel/livepatch/core.c > > >>> +++ b/kernel/livepatch/core.c > > >>> @@ -984,7 +988,12 @@ static void klp_free_patch(struct klp_patch *patch) > > >>> > > >>> static int klp_init_func(struct klp_object *obj, struct klp_func *func) > > >>> { > > >>> - if (!func->old_name || !func->new_func) > > >>> + if (!func->old_name) > > >>> + return -EINVAL; > > >>> + > > >>> + /* NOPs do not know the address until the patched module is loaded. */ > > >>> + if (!func->new_func && > > >>> + (!klp_is_func_type(func, KLP_FUNC_NOP) || klp_is_object_loaded(obj))) > > >>> return -EINVAL; > > >> > > >> If we changed the order of klp_init_func() and klp_init_object_loaded() > > >> calls in klp_init_object(), the hunk would not be needed. Is that correct? > > > > > > Not really. klp_init_object_loaded() would set func->new_func only > > > when the object was loaded. But we want to proceed here and create > > > the kobject for NOPs even when it was not loaded. Anyway, the above check have to be updated after we removed the redundant func->new_func assignment in klp_alloc_func_nop(). func->new_func is always NULL for NOPs in klp_init_func(). It is set later in klp_init_object_loaded(). I am going to use the following check in v10: /* * NOPs get the address later. The the patched module must be loaded, * see klp_init_object_loaded(). */ if (!func->new_func && !klp_is_func_type(func, KLP_FUNC_NOP)) return -EINVAL; > > > > > >>> INIT_LIST_HEAD(&func->stack_node); > > >>> @@ -1039,6 +1048,9 @@ static int klp_init_object_loaded(struct klp_patch *patch, > > >>> return -ENOENT; > > >>> } > > >>> > > >>> + if (klp_is_func_type(func, KLP_FUNC_NOP)) > > >>> + func->new_func = (void *)func->old_addr; > > >> > > >> Is there a reason why you left the same assignment in > > >> klp_alloc_func_nop()? This one is enough, no? > > > > > > Good point! I am going to replace the obsolete assignment > > > with a comment in v8. > > > > Hi Petr, Miroslav, > > > > I don't think the assignment in klp_alloc_func_nop() was necessarily > > redundant. It was removed in v9 and that breaks my atomic replace > > sample module when I try to load it. (Perhaps the sample patch has > > issues, but here are my debug notes): Sigh, I hate "trivial" last minute clean ups ;-) > Ok, so it was not redundant. Or... I think it should be redundant, but we > need to define the if condition in klp_init_func() properly. Exactly, see above. > > I think this problem is contained to only replacement patches that need > > the nop-revert feature... if the replacement patch provides a new > > function definition, then it shouldn't be affected. > > > > Man, we need a regression test suite for all these cases :) It would be great... > Any volunteer? ? Best Regards, Petr