public inbox for live-patching@vger.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Marcos Paulo de Souza <mpdesouza@suse.com>
Cc: live-patching@vger.kernel.org, jpoimboe@redhat.com,
	mbenes@suse.cz, nstange@suse.de
Subject: Re: [PATCH 4/4] livepatch/shadow: Add garbage collection of shadow variables
Date: Thu, 25 Aug 2022 14:59:01 +0200	[thread overview]
Message-ID: <YwdyFbtOEuBgzbnl@alley> (raw)
In-Reply-To: <20220701194817.24655-5-mpdesouza@suse.com>

On Fri 2022-07-01 16:48:17, Marcos Paulo de Souza wrote:
> The life of shadow variables is not completely trivial to maintain.
> They might be used by more livepatches and more livepatched objects.
> They should stay as long as there is any user.
> 
> In practice, it requires to implement reference counting in callbacks
> of all users. They should register all the user and remove the shadow

s/all the user/all users/

> variables only when there is no user left.
> 
> This patch hides the reference counting into the klp_shadow API.
> The counter is connected with the shadow variable @id. It requires
> an API to take and release the reference. The release function also
> calls the related dtor() when defined.
> 
> An easy solution would be to add some get_ref()/put_ref() API.
> But it would need to get called from pre()/post_un() callbacks.
> It might be easy to forget a callback and make it wrong.
> 
> A more safe approach is to associate the klp_shadow_type with
> klp_objects that use the shadow variables. The livepatch core
> code might then handle the reference counters on background.
> 
> The shadow variable type might then be added into a new @shadow_types
> member of struct klp_object. They will get then automatically registered
> and unregistered when the object is being livepatched. The registration
> increments the reference count. Unregistration decreases the reference
> count. All shadow variables of the given type are freed when the reference
> count reaches zero.
> 
> All klp_shadow_alloc/get/free functions also checks whether the requested
> type is registered. It will help to catch missing registration and might
> also help to catch eventual races.
> 
> --- a/include/linux/livepatch.h
> +++ b/include/linux/livepatch.h
> @@ -222,13 +226,30 @@ typedef void (*klp_shadow_dtor_t)(void *obj, void *shadow_data);
>   * @ctor:	custom constructor to initialize the shadow data (optional)
>   * @dtor:	custom callback that can be used to unregister the variable
>   *		and/or free data that the shadow variable points to (optional)
> + * @registered: flag indicating if the variable was successfully registered
> + *
> + * All shadow variables used by the livepatch for the related klp_object
> + * must be listed here so that they are registered when the livepatch
> + * and the module is loaded. Otherwise, it will not be possible to
> + * allocated them.

s/allocated/allocate/

>   */
>  struct klp_shadow_type {
>  	unsigned long id;
>  	klp_shadow_ctor_t ctor;
>  	klp_shadow_dtor_t dtor;
> +
> +	/* internal */
> +	bool registered;
>  };
>  
> +#define klp_for_each_shadow_type(obj, shadow_type, i)			\
> +	for (shadow_type = obj->shadow_types ? obj->shadow_types[0] : NULL, i = 1; \
> +	     shadow_type; \
> +	     shadow_type = obj->shadow_types[i++])
> +

> --- a/kernel/livepatch/shadow.c
> +++ b/kernel/livepatch/shadow.c
> @@ -307,3 +331,103 @@ void klp_shadow_free_all(struct klp_shadow_type *shadow_type)
>  	spin_unlock_irqrestore(&klp_shadow_lock, flags);
>  }
>  EXPORT_SYMBOL_GPL(klp_shadow_free_all);
> +
> +static struct klp_shadow_type_reg *
> +klp_shadow_type_get_reg(struct klp_shadow_type *shadow_type)
> +{
> +	struct klp_shadow_type_reg *shadow_type_reg;
> +	lockdep_assert_held(&klp_shadow_lock);
> +
> +	list_for_each_entry(shadow_type_reg, &klp_shadow_types, list) {
> +		if (shadow_type_reg->id == shadow_type->id)
> +			return shadow_type_reg;
> +	}
> +
> +	return NULL;
> +}
> +
> +/**
> + * klp_shadow_register() - register self for using a given data identifier

This is a relic from a former version. It should be something like:

 * klp_shadow_register() - register the given shadow variable type


> + * @shadow_type:	shadow type to be registered
> + *
> + * Tell the system that the related module (livepatch) is going to use a given
> + * shadow variable ID. It allows to check and maintain lifetime of shadow
> + * variables.

Same here. It should be:

 * Tell the system that the given shadow variable ID is going to be used by
 * the caller (livepatch module). It allows to check and maintain the lifetime
 * of shadow variables.

> + *
> + * Return: 0 on suceess, -ENOMEM when there is not enough memory.
> + */
> +int klp_shadow_register(struct klp_shadow_type *shadow_type)
> +{
> +	struct klp_shadow_type_reg *shadow_type_reg;
> +	struct klp_shadow_type_reg *new_shadow_type_reg;
> +

The code looks good to me. With the above changes:

Reviewed-by: Petr Mladek <pmladek@suse.com>

Best Regards,
Petr

  reply	other threads:[~2022-08-25 12:59 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-01 19:48 [PATCH 0/4] livepatch: Add garbage collection for shadow variables Marcos Paulo de Souza
2022-07-01 19:48 ` [PATCH 1/4] livepatch/shadow: Separate code to get or use pre-allocated shadow variable Marcos Paulo de Souza
2022-07-01 21:01   ` Josh Poimboeuf
2022-07-29 15:06   ` Petr Mladek
2022-07-01 19:48 ` [PATCH 2/4] livepatch/shadow: Separate code removing all shadow variables for a given id Marcos Paulo de Souza
2022-07-29 15:09   ` Petr Mladek
2022-07-01 19:48 ` [PATCH 3/4] livepatch/shadow: Introduce klp_shadow_type structure Marcos Paulo de Souza
2022-07-01 21:04   ` Josh Poimboeuf
2022-07-29 16:07   ` Petr Mladek
2022-08-25 14:50   ` Joe Lawrence
2022-08-25 14:54     ` Joe Lawrence
2022-10-24 13:24       ` Petr Mladek
2022-10-24 12:59     ` Petr Mladek
2022-07-01 19:48 ` [PATCH 4/4] livepatch/shadow: Add garbage collection of shadow variables Marcos Paulo de Souza
2022-08-25 12:59   ` Petr Mladek [this message]
2022-08-25 16:26   ` Joe Lawrence
2022-10-24 15:09     ` Petr Mladek
2022-11-01 11:02       ` Petr Mladek
2022-11-02 12:51         ` Joe Lawrence
2022-11-04 14:44           ` Joe Lawrence

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YwdyFbtOEuBgzbnl@alley \
    --to=pmladek@suse.com \
    --cc=jpoimboe@redhat.com \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    --cc=mpdesouza@suse.com \
    --cc=nstange@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox