[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160428182131.GA22885@packer-debian-8-amd64.digitalocean.com>
Date: Thu, 28 Apr 2016 14:21:31 -0400
From: Jessica Yu <jeyu@...hat.com>
To: Miroslav Benes <mbenes@...e.cz>
Cc: jpoimboe@...hat.com, jikos@...nel.org, pmladek@...e.com,
live-patching@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: klp: make object/func-walking helpers more robust
+++ Miroslav Benes [28/04/16 16:34 +0200]:
>Current object-walking helper checks the presence of obj->funcs to
>determine the end of objs array in klp_object structure. This is
>somewhat fragile because one can easily forget about funcs definition
>during livepatch creation. In such a case the livepatch module is
>successfully loaded and all objects after the incorrect one are omitted.
>This is very confusing. Let's make the helper more robust and check also
>for the other external member, name. Thus the helper correctly stops on
>an empty item of the array. We need to have a check for obj->funcs in
>klp_init_object() to make it work.
>
>The same applies to a func-walking helper.
>
>As a benefit we'll check for new_func member definition during the
>livepatch initialization. There is no such check anywhere in the code
>now.
>
>Signed-off-by: Miroslav Benes <mbenes@...e.cz>
>---
> include/linux/livepatch.h | 6 ++++--
> kernel/livepatch/core.c | 3 +++
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
>diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
>index 0933ca47791c..a93a0b23dc8d 100644
>--- a/include/linux/livepatch.h
>+++ b/include/linux/livepatch.h
>@@ -104,10 +104,12 @@ struct klp_patch {
> };
>
> #define klp_for_each_object(patch, obj) \
>- for (obj = patch->objs; obj->funcs; obj++)
>+ for (obj = patch->objs; obj->funcs || obj->name; obj++)
Remember that for patches to vmlinux, obj->name and obj->mod will also
both be NULL. So if someone happens to forget to fill in obj->funcs
for a vmlinux patch, we won't catch that case here. Perhaps we need a
better way of determining whether we've reached the end of the array,
or determining that the struct is truly empty..
Jessica
Powered by blists - more mailing lists