Received: by 10.213.65.68 with SMTP id h4csp718927imn; Wed, 4 Apr 2018 06:11:42 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/Fr5Zo76Y2gPTbyZWJtfvOmwWH4gHDBTRIVA3yZO4JrBrh/ZuEnhoG2YO3bmW5P4h5XDIl X-Received: by 10.98.9.147 with SMTP id 19mr7308637pfj.125.1522847501961; Wed, 04 Apr 2018 06:11:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522847501; cv=none; d=google.com; s=arc-20160816; b=e6X8frwF/72W/JodgE3ENcQvG0EubMcPTwTGHk1GuNUM8kqlnsM2beKVynHdA8HQOC FHwvdPtewZn5ND7iZ6RWlqkk8sPsnf0L95Ko+f/nfzA6Wv0Rr/174oc/FY+s+v8bAKlc j+EUfF2qN6O43SmP7m9q6rCqxLXM2SQ7EI+wk74KhnNXyJmbDCGyqkES/vgqWzToYNy3 Jq2DN2aMnO0D0Bl2lIAh0TYQCuOw4Ecc1kgjcYDufk0o5dlVBEP/vuYTzhqzMUA8eF/F qIgcwZ5gkABGqzzM1HDM5CU7we331kaMrVheyy7bCEH/Gp9pw5E1AoZg1WglqHDkzTKq AxTg== 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=iQTsXc7GB0yPiW8W8AGYRtZMFLQzqaF44tivVyt6CNM=; b=J1po2LiA+C/hAxWrxHFtfPS+TLstMTEB9BrYV2yak9mBmAzOrdeRUvy2DOGNO9ItJo 2K5x6Kh2Hn3Aj8OrLaL5NsCdgGIyMgisYUnN6PTvrLw/zccfflWQch4rbCcGpaztpPKo XG8c6Tc5qy4k9/tYnICD7guZP0fs0OVSkg9Tg3J4XOSptNxFBEX5DuyNIs0DUmySaliS GDvZ9aB74HlsH34E1WrAxxgorifpLR2yA1EBb25vWkbBTsdVhdMntsiSEgaM03xLZJKi hCBqK6Up5xwL2zC0oC++l8e8Hdc6wXJILV/K0fzPRkMc2VEjJ+eeDXI6qd5fNAJDwZLm OOPA== 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 e9-v6si3081070pln.439.2018.04.04.06.11.26; Wed, 04 Apr 2018 06:11: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 S1751306AbeDDNIx (ORCPT + 99 others); Wed, 4 Apr 2018 09:08:53 -0400 Received: from mx2.suse.de ([195.135.220.15]:44563 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750842AbeDDNIw (ORCPT ); Wed, 4 Apr 2018 09:08:52 -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 ACCB9ADAE; Wed, 4 Apr 2018 13:08:50 +0000 (UTC) Date: Wed, 4 Apr 2018 15:08:50 +0200 From: Petr Mladek To: Josh Poimboeuf Cc: Joe Lawrence , Jiri Kosina , Miroslav Benes , Jessica Yu , Nicolai Stange , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 1/2] livepatch: Initialize shadow variables by init function safely Message-ID: <20180404130850.5wnhj3rnc7iwvosu@pathway.suse.cz> References: <20180313155448.1998-1-pmladek@suse.com> <20180313155448.1998-2-pmladek@suse.com> <20180314192702.h6fvqoo7myt426ww@redhat.com> <20180314194436.fl5xro6aixroqzxk@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180314194436.fl5xro6aixroqzxk@treble> 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 Wed 2018-03-14 14:44:36, Josh Poimboeuf wrote: > On Wed, Mar 14, 2018 at 03:27:02PM -0400, Joe Lawrence wrote: > > On Tue, Mar 13, 2018 at 04:54:47PM +0100, Petr Mladek wrote: > > > The existing API allows to pass a sample data to initialize the shadow > > > data. It works well when the data are position independent. But it fails > > > miserably when we need to set a pointer to the shadow structure itself. > > > > > > Unfortunately, we might need to initialize the pointer surprisingly > > > often because of struct list_head. It is even worse because the list > > > might be hidden in other common structures, for example, struct mutex, > > > struct wait_queue_head. > > > > > > This patch makes the API more safe. A custom init function and data > > > are passed to klp_shadow_*alloc() functions instead of the sample data. > > > > Yup, this looks kinda familiar, I remember tinkering with the same idea > > last year [1] before settling on the simpler API. > > > > [1] https://github.com/torvalds/linux/compare/master...joe-lawrence:shadow_variables_v2_c > > > > > Note that the init_data are not longer a template for the shadow->data. > > > It might point to any data that might be necessary when the init > > > function is called. > > > > I'm not opposed to changing the API, but I was wondering if you had > > thought about expanding it as an alternative? > > > > When working on this last summer, I remember holding onto to some less > > than intuitive naming conventions so that I could support a basic API > > and an extended API with bells and whistles like this patchset > > implements. It didn't seem too difficult to layer the basic API ontop > > of one like this (see [1] for example), so maybe that's an option to > > keep basic shadow variable usage a little simpler. /two cents > > I like Petr's new API. It's not a big deal to just pass a couple of > NULLs if you don't need the callback. > > And I prefer fewer functions anyway -- maybe it's my functionitis > allergies acting up again. Yeah, I think that that two APIs might cause confusion. Especially because *data and *init_data have different meaning. I would prefer to keep only the first one. > > Perhaps shadow variables are another candidate for some kind of > > kselftest? > > Indeed! It would be great. Best Regards, Petr PS: Thanks all for the feedback.