On Mon, 21 Aug 2017, Joe Lawrence wrote: > diff --git a/Documentation/livepatch/shadow-vars.txt b/Documentation/livepatch/shadow-vars.txt > new file mode 100644 > index 000000000000..d7558a1e4797 > --- /dev/null > +++ b/Documentation/livepatch/shadow-vars.txt > @@ -0,0 +1,191 @@ > + > +Matching parent's lifecycle > +--------------------------- > + > +If parent data structures are frequently created and destroyed, it may > +be easiest to align their shadow variables lifetimes to the same > +allocation and release functions. In this case, the parent data > +structure is typically allocated, initialized, then registered in some > +manner. Shadow variable allocation and setup can then be considered > +part of the parent's initialization and should be completed before the > +parent "goes live" (ie, any shadow variable get-API requests are made > +for this <obj, id> pair. ')' is missing. > diff --git a/kernel/livepatch/shadow.c b/kernel/livepatch/shadow.c > new file mode 100644 > index 000000000000..83ca71454584 > --- /dev/null > +++ b/kernel/livepatch/shadow.c > @@ -0,0 +1,295 @@ > +/* > + * shadow.c - Shadow Variables > + * > + * Copyright (C) 2014 Josh Poimboeuf <jpoimboe@xxxxxxxxxx> > + * Copyright (C) 2014 Seth Jennings <sjenning@xxxxxxxxxx> > + * Copyright (C) 2017 Joe Lawrence <joe.lawrence@xxxxxxxxxx> > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License > + * as published by the Free Software Foundation; either version 2 > + * of the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, see <http://www.gnu.org/licenses/>. > + */ > + > +/** > + * DOC: Shadow variable API concurrency notes: > + * > + * The shadow variable API provides a simple relationship between an > + * <obj, id> pair and a pointer value. It is the responsibility of the > + * caller to provide any mutual exclusion required of the shadow data. I think that the last sentence should appear somewhere in the documentation. > +void *__klp_shadow_get_or_alloc(void *obj, unsigned long id, void *data, > + size_t size, gfp_t gfp_flags, > + enum klp_shadow_existing_handling existing_handling) > +{ > + struct klp_shadow *new_shadow; > + void *shadow_data; > + unsigned long flags; > + > + /* Check if the shadow variable if <obj, id> already exists */ > + shadow_data = klp_shadow_get(obj, id); > + if (shadow_data) > + goto exists; > + > + /* Allocate a new shadow variable for use inside the lock below */ > + new_shadow = kzalloc(size + sizeof(*new_shadow), gfp_flags); > + if (!new_shadow) > + return NULL; > + > + new_shadow->obj = obj; > + new_shadow->id = id; > + > + /* Initialize the shadow variable if data provided */ > + if (data) > + memcpy(new_shadow->data, data, size); > + > + /* Look for <obj, id> again under the lock */ > + spin_lock_irqsave(&klp_shadow_lock, flags); > + shadow_data = klp_shadow_get(obj, id); > + if (unlikely(shadow_data)) { > + /* > + * Shadow variable was found, throw away speculative > + * allocation and update/return the existing one. > + */ The comment is outdated. Miroslav -- To unsubscribe from this list: send the line "unsubscribe live-patching" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
