Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1665797 > unrolled thread

Re: [PATCH 1/3] livepatch: introduce shadow variable API

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 1/3] livepatch: introduce shadow variable API Petr Mladek <pmladek@suse.com> - 2017-06-14 15:00 +0200
    Re: [PATCH 1/3] livepatch: introduce shadow variable API Josh Poimboeuf <jpoimboe@redhat.com> - 2017-06-14 15:20 +0200
      Re: [PATCH 1/3] livepatch: introduce shadow variable API Petr Mladek <pmladek@suse.com> - 2017-06-14 16:30 +0200
    Re: [PATCH 1/3] livepatch: introduce shadow variable API Miroslav Benes <mbenes@suse.cz> - 2017-06-19 18:20 +0200

#1665797 — Re: [PATCH 1/3] livepatch: introduce shadow variable API

On Thu 2017-06-01 14:25:24, 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.

It would be great to explain what shadow variables mean
here. Alternatively I would sqash the 2nd patch into this one.

People might use git blame to search what this API/code is for
and this commit not give much hints.

> diff --git a/kernel/livepatch/shadow.c b/kernel/livepatch/shadow.c
> new file mode 100644
> index 000000000000..72d5e567dff9
> --- /dev/null
> +++ b/kernel/livepatch/shadow.c
> @@ -0,0 +1,115 @@
> +/*
> + * shadow.c - Shadow Variables
> + *
> + * Copyright (C) 2014 Josh Poimboeuf <jpoimboe@redhat.com>
> + * Copyright (C) 2014 Seth Jennings <sjenning@redhat.com>
> + * Copyright (C) 2017 Joe Lawrence <joe.lawrence@redhat.com>
> + *
> + * 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/>.
> + */
> +
> +#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
> +
> +#include <linux/hashtable.h>
> +#include <linux/slab.h>
> +#include <linux/livepatch.h>
> +
> +static DEFINE_HASHTABLE(klp_shadow_hash, 12);
> +static DEFINE_SPINLOCK(klp_shadow_lock);
> +

Please, add comment that will explain the structure members.
See include/linux/livepatch.h for explanation.

> +struct klp_shadow {
> +	struct hlist_node node;
> +	struct rcu_head rcu_head;
> +	void *obj;
> +	char *var;
> +	void *data;

I would make the meaning more obvious. What about renaming?

  var -> key or id
  data -> shadow_obj or new_obj

> +};
> +

Also the function would deserve a comment explaining the meaning
and parameters.

> +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);

I would use int or long instead of "char *". You do not know
in which context the API will be used. strdup() might be
unnecessarily expensive. You could always use enum or #define
to get readable names for the key.


> +	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);
> +
> +static void klp_shadow_rcu_free(struct rcu_head *head)
> +{
> +	struct klp_shadow *shadow;
> +
> +	shadow = container_of(head, struct klp_shadow, rcu_head);
> +
> +	kfree(shadow->var);
> +	kfree(shadow);

If we use int/long instead of the string, we will do not
need a custom free function. free_rcu() will work then.

> +}
> +
> +void klp_shadow_detach(void *obj, char *var)
> +{
> +	unsigned long flags;
> +	struct klp_shadow *shadow;
> +
> +	spin_lock_irqsave(&klp_shadow_lock, flags);
> +
> +	hash_for_each_possible(klp_shadow_hash, shadow, node,
> +			       (unsigned long)obj) {
> +		if (shadow->obj == obj && !strcmp(shadow->var, var)) {

Do we need to test "shadow->obj == obj" here? If it is not true,
there would be a bug in the hashtable implementation or in
klp_shadow_attach().

Well, it might make sense to add a consistency check:

      WARN_ON(shadow->obj != obj);


> +			hash_del_rcu(&shadow->node);
> +			spin_unlock_irqrestore(&klp_shadow_lock, flags);
> +			call_rcu(&shadow->rcu_head, klp_shadow_rcu_free);

call_rcu() just queues the request. It does not wait for it.
It can be called inside the lock and the code might
be easier:

			hash_del_rcu(&shadow->node);
			call_rcu(&shadow->rcu_head,
				  klp_shadow_rcu_free);
			break;
		}
	}
	spin_unlock_irqrestore(&klp_shadow_lock, flags);
}


Otherwise, I like that the API rather trivial and still useful.

Best Regards,
Petr

[toc] | [next] | [standalone]

#1665822

On Wed, Jun 14, 2017 at 02:59:13PM +0200, Petr Mladek wrote:
> > +}
> > +
> > +void klp_shadow_detach(void *obj, char *var)
> > +{
> > +	unsigned long flags;
> > +	struct klp_shadow *shadow;
> > +
> > +	spin_lock_irqsave(&klp_shadow_lock, flags);
> > +
> > +	hash_for_each_possible(klp_shadow_hash, shadow, node,
> > +			       (unsigned long)obj) {
> > +		if (shadow->obj == obj && !strcmp(shadow->var, var)) {
> 
> Do we need to test "shadow->obj == obj" here? If it is not true,
> there would be a bug in the hashtable implementation or in
> klp_shadow_attach().
> 
> Well, it might make sense to add a consistency check:
> 
>       WARN_ON(shadow->obj != obj);
> 

It would make sense if hash_for_each_possible() worked that way, but for
some reason it doesn't. :-/  It gives you all the hash collisions.

-- 
Josh

[toc] | [prev] | [next] | [standalone]

#1665876

On Wed 2017-06-14 08:17:44, Josh Poimboeuf wrote:
> On Wed, Jun 14, 2017 at 02:59:13PM +0200, Petr Mladek wrote:
> > > +}
> > > +
> > > +void klp_shadow_detach(void *obj, char *var)
> > > +{
> > > +	unsigned long flags;
> > > +	struct klp_shadow *shadow;
> > > +
> > > +	spin_lock_irqsave(&klp_shadow_lock, flags);
> > > +
> > > +	hash_for_each_possible(klp_shadow_hash, shadow, node,
> > > +			       (unsigned long)obj) {
> > > +		if (shadow->obj == obj && !strcmp(shadow->var, var)) {
> > 
> > Do we need to test "shadow->obj == obj" here? If it is not true,
> > there would be a bug in the hashtable implementation or in
> > klp_shadow_attach().
> > 
> > Well, it might make sense to add a consistency check:
> > 
> >       WARN_ON(shadow->obj != obj);
> > 
> 
> It would make sense if hash_for_each_possible() worked that way, but for
> some reason it doesn't. :-/  It gives you all the hash collisions.

I see. Shame on me. The original code makes perfect sense then.

Best Regards,
Petr

[toc] | [prev] | [next] | [standalone]

#1669445

> > +struct klp_shadow {
> > +	struct hlist_node node;
> > +	struct rcu_head rcu_head;
> > +	void *obj;
> > +	char *var;
> > +	void *data;
> 
> I would make the meaning more obvious. What about renaming?
> 
>   var -> key or id
>   data -> shadow_obj or new_obj

But var is not a key to a hash table. obj is. Renaming obj to key would be 
misleading in my opinion, because it IS a pointer to an object. And data 
is ok too, as far as I'm concerned. Just saying.

But yes, I'd welcome a description too.

Miroslav

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web