From: zhang warden <zhangwarden@gmail.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Miroslav Benes <mbenes@suse.cz>,
Josh Poimboeuf <jpoimboe@kernel.org>,
Jiri Kosina <jikos@kernel.org>,
Joe Lawrence <joe.lawrence@redhat.com>,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 2/2] livepatch: Add using attribute to klp_func for using function show
Date: Tue, 10 Sep 2024 16:09:46 +0800 [thread overview]
Message-ID: <35E63D8A-6C19-4EAC-94A3-0A5F74AE679F@gmail.com> (raw)
In-Reply-To: <Zt_86rOMJN4UFEk-@pathway.suse.cz>
Hi, Petr
> On Sep 10, 2024, at 16:01, Petr Mladek <pmladek@suse.com> wrote:
>
> On Sun 2024-09-08 10:51:14, zhang warden wrote:
>>
>> Hi, Petr
>>>
>>> The 1st patch adds the pointer to struct klp_ops into struct
>>> klp_func. We might check the state a similar way as klp_ftrace_handler().
>>>
>>> I had something like this in mind when I suggested to move the pointer:
>>>
>>> static ssize_t using_show(struct kobject *kobj,
>>> struct kobj_attribute *attr, char *buf)
>>> {
>>> struct klp_func *func, *using_func;
>>> struct klp_ops *ops;
>>> int using;
>>>
>>> func = container_of(kobj, struct klp_func, kobj);
>>>
>>> rcu_read_lock();
>>>
>>> if (func->transition) {
>>> using = -1;
>>> goto out;
>>> }
>>>
>>> # FIXME: This requires releasing struct klp_ops via call_rcu()
>
> This would require adding "struct rcu_head" into "struct klp_ops",
> like:
>
> struct klp_ops {
> struct list_head func_stack;
> struct ftrace_ops fops;
> struct rcu_head rcu;
> };
>
> and then freeing the structure using kfree_rcu():
>
> diff --git a/kernel/livepatch/patch.c b/kernel/livepatch/patch.c
> index 90408500e5a3..f096dd9390d2 100644
> --- a/kernel/livepatch/patch.c
> +++ b/kernel/livepatch/patch.c
> @@ -149,7 +149,7 @@ static void klp_unpatch_func(struct klp_func *func)
>
> list_del_rcu(&func->stack_node);
> list_del(&ops->node);
> - kfree(ops);
> + kfree_rcu(ops, rcu);
> } else {
> list_del_rcu(&func->stack_node);
> }
> @@ -223,7 +223,7 @@ static int klp_patch_func(struct klp_func *func)
> err:
> list_del_rcu(&func->stack_node);
> list_del(&ops->node);
> - kfree(ops);
> + kfree_rcu(ops, rcu);
> return ret;
> }
>
> With this the function should be safe against accessing an invalid
> pointer.
>
>>> ops = func->ops;
>>> if (!ops) {
>>> using = 0;
>>> goto out;
>>> }
>>>
>>> using_func = list_first_or_null_rcu(&ops->func_stack,
>>> struct klp_func, stack_node);
>>> if (func == using_func)
>>> using = 1;
>>> else
>>> using = 0;
>>>
>>> out:
>>> rcu_read_unlock();
>>>
>>> return sysfs_emit(buf, "%d\n", func->using);
>>> }
>
> But the function is still not correct according the order of reading.
> A more correct solution would be something like:
>
> static ssize_t using_show(struct kobject *kobj,
> struct kobj_attribute *attr, char *buf)
> {
> struct klp_func *func, *using_func;
> struct klp_ops *ops;
> int using;
>
> func = container_of(kobj, struct klp_func, kobj);
>
> rcu_read_lock();
>
> /* This livepatch is used when the function is on top of the stack. */
> ops = func->ops;
> if (ops) {
> using_func = list_first_or_null_rcu(&ops->func_stack,
> struct klp_func, stack_node);
> if (func == using_func)
> using = 1;
> else
> using = 0;
> }
>
> /*
> * The function stack gives the right information only when there
> * is no transition in progress.
> *
> * Make sure that we see the updated ops->func_stack when
> * func->transition is cleared. This matches with:
> *
> * The write barrier in __klp_enable_patch() between
> * klp_init_transition() and klp_patch_object().
> *
> * The write barrier in __klp_disable_patch() between
> * klp_init_transition() and klp_start_transition().
> *
> * The write barrier in klp_complete_transition()
> * between klp_unpatch_objects() and func->transition = false.
> */
> smp_rmb();
>
> if (func->transition)
> using = -1;
>
> rcu_read_unlock();
>
> return sysfs_emit(buf, "%d\n", func->using);
> }
>
> Now, the question is whether we want to maintain such a barrier. Any
> lockless access and barrier adds a maintenance burden.
>
> You might try to put the above into a patch see what others tell
> about it.
>
> Best Regards,
> Petr
After the previous discussion, it seems that patch-level "order" feature
is the more acceptable way to fulfill the patch order information.
Therefore, I am trying to go that way instead of adding "using" into klp_func.
Maybe patch-level interface will bring less maintenance burden.
Regards,
Wardenjohn.
prev parent reply other threads:[~2024-09-10 8:10 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-28 2:23 [PATCH v4 0/2] livepatch: Add using attribute to klp_func for using function Wardenjohn
2024-08-28 2:23 ` [PATCH v4 1/2] Introduce klp_ops into klp_func structure Wardenjohn
2024-09-05 10:10 ` Miroslav Benes
2024-09-05 14:33 ` zhang warden
2024-09-06 7:03 ` Miroslav Benes
2024-09-06 9:44 ` zhang warden
2024-09-13 9:46 ` zhang warden
2024-08-28 2:23 ` [PATCH v4 2/2] livepatch: Add using attribute to klp_func for using function show Wardenjohn
2024-09-04 1:54 ` zhang warden
2024-09-04 4:48 ` Josh Poimboeuf
2024-09-04 6:34 ` zhang warden
2024-09-04 7:14 ` Josh Poimboeuf
2024-09-04 7:30 ` zhang warden
2024-09-04 18:06 ` Josh Poimboeuf
2024-09-05 14:03 ` zhang warden
2024-09-05 16:30 ` Josh Poimboeuf
2024-09-05 10:23 ` Miroslav Benes
2024-09-05 14:17 ` zhang warden
2024-09-05 16:34 ` Josh Poimboeuf
2024-09-06 6:55 ` Miroslav Benes
2024-09-06 9:39 ` zhang warden
2024-09-06 16:39 ` Petr Mladek
2024-09-08 2:31 ` zhang warden
2024-09-06 16:13 ` Petr Mladek
2024-09-08 2:51 ` zhang warden
2024-09-10 8:01 ` Petr Mladek
2024-09-10 8:09 ` zhang warden [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=35E63D8A-6C19-4EAC-94A3-0A5F74AE679F@gmail.com \
--to=zhangwarden@gmail.com \
--cc=jikos@kernel.org \
--cc=joe.lawrence@redhat.com \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=pmladek@suse.com \
/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
all inboxes | Powered by JetHome®