> > > +/*
> > > + * klp_shadow_set() - initialize a shadow variable
> > > + * @shadow: shadow variable to initialize
> > > + * @obj: pointer to parent object
> > > + * @id: data identifier
> > > + * @data: pointer to data to attach to parent
> > > + * @size: size of attached data
> > > + */
> > > +static inline void klp_shadow_set(struct klp_shadow *shadow, void *obj,
> > > + unsigned long id, void *data, size_t size)
> > > +{
> > > + shadow->obj = obj;
> > > + shadow->id = id;
> > > +
> > > + if (data)
> > > + memcpy(shadow->data, data, size);
> > > +}
> > > +
> > > +/**
> > > + * klp_shadow_add() - add a shadow variable to the hashtable
> > > + * @shadow: shadow variable to add
> > > + */
> > > +static inline void klp_shadow_add(struct klp_shadow *shadow)
> > > +{
> > > + hash_add_rcu(klp_shadow_hash, &shadow->node,
> > > + (unsigned long)shadow->obj);
> > > +}
> >
> > It would be nice to add a comment that a caller must hold klp_shadow_lock
> > spinlock.
>
> Since shadow_match(), klp_shadow_set(), and klp_shadow_add() are all in
> the same boat, I can mention the lock for those functions as well.
Yes, please.
> BTW,
> is there a convention to drop the "klp_" for static, local routines? I
> should be consistent here.
Oh, I didn't notice missing "klp_" in shadow_match. We have a prefix
everywhere, so add it, please.
Thanks,
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
