Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp343174imm; Fri, 31 Aug 2018 01:52:14 -0700 (PDT) X-Google-Smtp-Source: ANB0VdaZyrsNMJrLLmTqSGoAei3527Kj+wbiHUl8cjLQy1bA2n94K5Z5yimUjcmZFIK7CzLzo/L6 X-Received: by 2002:a65:6110:: with SMTP id z16-v6mr13672997pgu.412.1535705534892; Fri, 31 Aug 2018 01:52:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1535705534; cv=none; d=google.com; s=arc-20160816; b=zjBpFSK1ZdArbA5fknPDu2/KKgcGjM/LWhlqbaF9Hc8USfbkiGYdtLj4ejCYW3JcTJ oVOfRKrWprkyEQZaauZmgNnRiTE1vVXxiBldoVPiWdHHCTHpDhJlwSeUchlc90euVEH7 c8CR9Q2Pi53QDimDowPnR+Vq4yQaUfP7PxNqnRPZxRN2DI6pork6M39gN4mgGIDVCKU2 oQ36s0oplyjRgXxCH0S6KZvanLNUb160XY9IhMT3svKVzebxe/H6mmU9idMq9QVnlFIA pWOpldTPhoNQbjV5+N84I8qCJ/MsyDaKop/2W74FTvguf69HUaKEAsBWSuvDp9theKIt E1XA== 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=auGoyUNeuHI9MGbOgi2Za6nIVR5rflt0jfecSboviRM=; b=G3+rBx8nNqnxFekwWxldsddFowYehto/M02s4nmZVre2y+MtXr3abI241qZZ5EQymd A01zERfXiFdG+2pJBBrpMymk+1vkRn/zkpwSmojSk4C5NF8jx4nZKM/2pkpGTN9k7FeO gyXTMUGpUGmAxSm3md3GnY0+K75FtTYOaogbGcT5vXTGOSbSNkq9NlbBWsBza8kReXP8 qsO6F0WvN8HqQfaoBQuXbFo2wwoemOz9H1cpSiVo0DcWOheNnu3FN3gh2caFzdcVRZzF 2C0Wf/ILmCr0XLEvZhtHgSL2iQLP6yoADx53HwShmw2ncNYfxUmz+n2gAXebSHCxoZ+D gQMQ== 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 o7-v6si8068888pgi.53.2018.08.31.01.52.00; Fri, 31 Aug 2018 01:52:14 -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 S1727985AbeHaMoA (ORCPT + 99 others); Fri, 31 Aug 2018 08:44:00 -0400 Received: from mx2.suse.de ([195.135.220.15]:51336 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727568AbeHaMoA (ORCPT ); Fri, 31 Aug 2018 08:44:00 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 49B7CAEBC; Fri, 31 Aug 2018 08:37:37 +0000 (UTC) Date: Fri, 31 Aug 2018 10:37:36 +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 v12 01/12] livepatch: Change void *new_func -> unsigned long new_addr in struct klp_func In-Reply-To: <20180828143603.4442-2-pmladek@suse.com> Message-ID: References: <20180828143603.4442-1-pmladek@suse.com> <20180828143603.4442-2-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 Tue, 28 Aug 2018, Petr Mladek wrote: > The address of the to be patched function and new function is stored > in struct klp_func as: > > void *new_func; > unsigned long old_addr; > > The different naming scheme and type is derived from the way how > the addresses are set. @old_addr is assigned at runtime using > kallsyms-based search. @new_func is statically initialized, > for example: > > static struct klp_func funcs[] = { > { > .old_name = "cmdline_proc_show", > .new_func = livepatch_cmdline_proc_show, > }, { } > }; > > This patch changes void *new_func -> unsigned long new_addr. It removes > some confusion when these address are later used in the code. It is > motivated by a followup patch that adds special NOP struct klp_func > where we want to assign func->new_func = func->old_addr respectively > func->new_addr = func->old_addr. > > This patch does not modify the existing behavior. > > IMPORTANT: This patch modifies ABI. The patches will need to use, > for example: > > static struct klp_func funcs[] = { > { > .old_name = "cmdline_proc_show", > .new_addr = (unsigned long)livepatch_cmdline_proc_show, > }, { } > }; > > Suggested-by: Josh Poimboeuf > Signed-off-by: Petr Mladek I'm not convinced the patch makes things any better. The next patch slightly improves it, but still. Is new_func really such a problem? Thanks, Miroslav