Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751936AbdFISec (ORCPT ); Fri, 9 Jun 2017 14:34:32 -0400 Received: from mx1.redhat.com ([209.132.183.28]:44182 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751639AbdFISea (ORCPT ); Fri, 9 Jun 2017 14:34:30 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 2DDD380C13 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jpoimboe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 2DDD380C13 Date: Fri, 9 Jun 2017 13:34:25 -0500 From: Josh Poimboeuf To: Joe Lawrence Cc: live-patching@vger.kernel.org, linux-kernel@vger.kernel.org, Jessica Yu , Jiri Kosina , Miroslav Benes , Petr Mladek Subject: Re: [PATCH 1/3] livepatch: introduce shadow variable API Message-ID: <20170609183425.qn4n45mwqewxavmb@treble> References: <1496341526-19061-1-git-send-email-joe.lawrence@redhat.com> <1496341526-19061-2-git-send-email-joe.lawrence@redhat.com> <20170608164923.mkbiwporqw4i2kxy@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 09 Jun 2017 18:34:30 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2187 Lines: 64 On Fri, Jun 09, 2017 at 11:36:27AM -0400, Joe Lawrence wrote: > On 06/08/2017 12:49 PM, Josh Poimboeuf wrote: > > On Thu, Jun 01, 2017 at 02:25:24PM -0400, Joe Lawrence wrote: > >> Add three exported API for livepatch modules: > >> > >> void *klp_shadow_attach(void *obj, char *var, gfp_t gfp, void *data); > >> void klp_shadow_detach(void *obj, char *var); > >> void *klp_shadow_get(void *obj, char *var); > >> > >> that implement "shadow" variables, which allow callers to associate new > >> shadow fields to existing data structures. > >> > >> Signed-off-by: Joe Lawrence > > > > Overall the patch looks good to me. It's a simple API but we've found > > it to be very useful for certain patches. > > > > One comment below: > > > >> +void *klp_shadow_attach(void *obj, char *var, gfp_t gfp, void *data) > >> +{ > >> + unsigned long flags; > >> + struct klp_shadow *shadow; > >> + > >> + shadow = kmalloc(sizeof(*shadow), gfp); > >> + if (!shadow) > >> + return NULL; > >> + > >> + shadow->obj = obj; > >> + > >> + shadow->var = kstrdup(var, gfp); > >> + if (!shadow->var) { > >> + kfree(shadow); > >> + return NULL; > >> + } > >> + > >> + shadow->data = data; > >> + > >> + spin_lock_irqsave(&klp_shadow_lock, flags); > >> + hash_add_rcu(klp_shadow_hash, &shadow->node, (unsigned long)obj); > >> + spin_unlock_irqrestore(&klp_shadow_lock, flags); > >> + > >> + return shadow->data; > >> +} > >> +EXPORT_SYMBOL_GPL(klp_shadow_attach); > > > > I wonder if we should worry about people misusing the API by calling > > klp_shadow_attach() for a shadow variable that already exists. Maybe we > > should add a check and return NULL if it already exists. > > > > I don't think the API (the shadow or the underlying hash table calls) > currently protects against double-adds... adding a check to do so would > probably need to occur with the klp_shadow_lock to protect against > concurrent detach calls. > > I could implement this protection in a v2, or leave it up to the caller. > What do you think? Yeah, I don't have a strong opinion either way. It's fine with me to leave it as it is and trust the patch author not to mess it up. -- Josh