Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752814AbdFMKTj (ORCPT ); Tue, 13 Jun 2017 06:19:39 -0400 Received: from mx2.suse.de ([195.135.220.15]:60396 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1752259AbdFMKTh (ORCPT ); Tue, 13 Jun 2017 06:19:37 -0400 Date: Tue, 13 Jun 2017 12:19:35 +0200 (CEST) From: Miroslav Benes To: Joe Lawrence cc: Jiri Kosina , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Josh Poimboeuf , Jessica Yu , Petr Mladek Subject: Re: [PATCH 0/3] livepatch: add shadow variable API In-Reply-To: Message-ID: References: <1496341526-19061-1-git-send-email-joe.lawrence@redhat.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 443 Lines: 11 > If you are referring to stacking livepatches ... to be honest I hadn't > thought of that scenario. In that case, we might be able to get away > with pushing something like this into the hash: > > klp #1: klp_shadow_attach(ptr, "shadow_var", ...) > klp #2: klp_shadow_attach(ptr, "shadow_var_v2", ...) I thought this was the reason to have a string there. Otherwise, a pointer to original data would be enough, wouldn't it? Miroslav