All of lore.kernel.org
 help / color / mirror / Atom feed
From: Petr Mladek <pmladek@suse.com>
To: Joe Lawrence <joe.lawrence@redhat.com>
Cc: live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Jessica Yu <jeyu@kernel.org>, Jiri Kosina <jikos@kernel.org>,
	Miroslav Benes <mbenes@suse.cz>
Subject: Re: [PATCH] livepatch: unpatch all klp_objects if klp_module_coming fails
Date: Mon, 2 Oct 2017 14:52:29 +0200	[thread overview]
Message-ID: <20171002125229.GF8637@pathway.suse.cz> (raw)
In-Reply-To: <1506626100-7800-1-git-send-email-joe.lawrence@redhat.com>

On Thu 2017-09-28 15:15:00, Joe Lawrence wrote:
> When an incoming module is considered for livepatching by
> klp_module_coming(), it iterates over multiple patches and multiple
> kernel objects in this order:
> 
> 	list_for_each_entry(patch, &klp_patches, list) {
> 		klp_for_each_object(patch, obj) {
> 
> which means that if one of the kernel objects fails to patch,
> klp_module_coming()'s error path needs to unpatch and cleanup any kernel
> objects that were already patched by a previous patch.
> 
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index b9628e43c78f..3d457e0bbe26 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -830,6 +830,42 @@ int klp_register_patch(struct klp_patch *patch)
>  }
>  EXPORT_SYMBOL_GPL(klp_register_patch);
>  
> +/*
> + * Revert patches (up to a given limit) to objects belonging to a given
> + * kernel module.  After unpatching such objects, the function also

"objects belonging to a module" sounds strange. In the livepatch
world: module == object. I would say something like:

	/* Remove parts of patches that touch a given kernel module.
	 * The list of proceed patches might be limited. When limit is
	 * NULL, all patches will be handled.
	 */


> + * frees them.  When limit is NULL, all patches to the given module will
> + * be reverted.
> + */
> +static void klp_cleanup_module_objects_limited(struct module *mod,
> +					       struct klp_patch *limit)
> +{

Same here with: "module_objects". What about?

     klp_cleanup_module_patches_limited(struct module *mod,
					struct klp_patch *limit)


> +	struct klp_patch *patch;
> +	struct klp_object *obj;
> +
> +	list_for_each_entry(patch, &klp_patches, list) {
> +		if (patch == limit)
> +			break;
> +
> +		klp_for_each_object(patch, obj) {
> +			if (!klp_is_module(obj) || strcmp(obj->name, mod->name))
> +				continue;
> +
> +			/*
> +			 * Only unpatch the module if the patch is enabled or
> +			 * is in transition.
> +			 */
> +			if (patch->enabled || patch == klp_transition_patch) {
> +				pr_notice("reverting patch '%s' on unloading module '%s'\n",
> +					  patch->mod->name, obj->mod->name);
> +				klp_unpatch_object(obj);
> +			}
> +
> +			klp_free_object_loaded(obj);
> +			break;

Heh, I was about to say OK for this patch. But then I noticed
this strange "break". It was already in the original code and
I wondered if it was OK.

It is OK. It is an optimization because this code handles
only one struct object in each patch. But it made me
to complain about the wording above ;-)

> +		}
> +	}
> +}
> +
>  int klp_module_coming(struct module *mod)
>  {
>  	int ret;

Otherwise the patch looks fine to me. Thanks a lot for handling
it separately.

Best Regards,
Petr

      reply	other threads:[~2017-10-02 12:52 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-28 19:15 [PATCH] livepatch: unpatch all klp_objects if klp_module_coming fails Joe Lawrence
2017-10-02 12:52 ` Petr Mladek [this message]

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=20171002125229.GF8637@pathway.suse.cz \
    --to=pmladek@suse.com \
    --cc=jeyu@kernel.org \
    --cc=jikos@kernel.org \
    --cc=joe.lawrence@redhat.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=live-patching@vger.kernel.org \
    --cc=mbenes@suse.cz \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.