[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v5 27/28] xsplice: Add support for shadow variables.
>>> On 24.03.16 at 21:00, <konrad.wilk@xxxxxxxxxx> wrote: > Shadow variables are a piece of infrastructure to be used by xsplice > modules. They are used to attach a new piece of data to an existing > structure in memory. An already known question again: Out of recent XSAs, how many needed such? I.e. can#t we put this off for now? > Martin Pohlack also mentions that using the SHADOW_SLOTS of small > prime numbers has the advantage of having a simple hash function. This reads kind of backwards. > +void xsplice_shadow_free(const void *obj, const char *var) > +{ > + struct shadow_var *entry, *shadow = NULL; > + unsigned int slot; > + struct hlist_node *next; > + > + slot = (unsigned long)obj % SHADOW_SLOTS; > + > + spin_lock(&shadow_lock); > + hlist_for_each_entry(entry, next, &shadow_tbl[slot], list) > + { > + if ( entry->obj == obj && > + !strcmp(entry->var, var) ) > + { > + shadow = entry; > + break; > + } > + } > + if (shadow) Coding style. > + { > + hlist_del(&shadow->list); > + xfree(shadow->data); > + xfree(shadow); > + } > + spin_unlock(&shadow_lock); > +} Uniqueness not being guaranteed by the allocation function, how can you free the first hit here ... > +void *xsplice_shadow_get(const void *obj, const char *var) > +{ > + struct shadow_var *entry; > + unsigned int slot; > + struct hlist_node *next; > + void *ret = NULL; > + > + slot = (unsigned long)obj % SHADOW_SLOTS; > + > + spin_lock(&shadow_lock); > + hlist_for_each_entry(entry, next, &shadow_tbl[slot], list) > + { > + if ( entry->obj == obj && > + !strcmp(entry->var, var) ) > + { > + ret = entry->data; > + break; > + } > + } > + > + spin_unlock(&shadow_lock); > + return ret; > +} .. or return the first match here? > +static int __init xsplice_shadow_init(void) > +{ > + int i; unsigned int > --- a/xen/include/xen/xsplice_patch.h > +++ b/xen/include/xen/xsplice_patch.h > @@ -56,4 +56,40 @@ typedef void (*xsplice_unloadcall_t)(void); > #define XSPLICE_UNLOAD_HOOK(_fn) \ > xsplice_unloadcall_t __attribute__((weak)) xsplice_unload_data > __section(".xsplice.hooks.unload") = _fn; > > + > +/* > + * The following definitions are to be used in patches. They are taken > + * from kpatch. > + */ > + > +/* > + * xsplice shadow variables > + * > + * These functions can be used to add new "shadow" fields to existing data > + * structures. For example, to allocate a "newpid" variable associated with > an > + * instance of task_struct, and assign it a value of 1000: > + * > + * struct task_struct *tsk = current; > + * int *newpid; > + * newpid = xsplice_shadow_alloc(tsk, "newpid", sizeof(int)); > + * if (newpid) > + * *newpid = 1000; > + * > + * To retrieve a pointer to the variable: > + * > + * struct task_struct *tsk = current; > + * int *newpid; > + * newpid = xsplice_shadow_get(tsk, "newpid"); > + * if (newpid) > + * printk("task newpid = %d\n", *newpid); // prints "task newpid = 1000" > + * > + * To free it: > + * > + * xsplice_shadow_free(tsk, "newpid"); > + */ While this indeed provides some basic understanding, I think this should be using a more Xen-affine example, and I fail to see how with particularly the example given this is going to be useful: How would the patch module sanely and within reasonable time get hold of all instances of a particular type? Jan _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |