From: Miroslav Benes <mbenes@suse.cz>
To: zhang warden <zhangwarden@gmail.com>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
Jiri Kosina <jikos@kernel.org>, Petr Mladek <pmladek@suse.com>,
Joe Lawrence <joe.lawrence@redhat.com>,
live-patching@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4 1/2] Introduce klp_ops into klp_func structure
Date: Fri, 6 Sep 2024 09:03:34 +0200 (CEST) [thread overview]
Message-ID: <alpine.LSU.2.21.2409060857130.1385@pobox.suse.cz> (raw)
In-Reply-To: <EF43117B-DF46-4001-A5D4-49304EFF21AD@gmail.com>
Hi,
On Thu, 5 Sep 2024, zhang warden wrote:
>
> Hi, Miroslav
> > On Sep 5, 2024, at 18:10, Miroslav Benes <mbenes@suse.cz> wrote:
> >
> > Hi,
> >
> > the subject is missing "livepatch: " prefix and I would prefer something
> > like
> >
> > "livepatch: Move struct klp_ops to struct klp_func"
> >
> > On Wed, 28 Aug 2024, Wardenjohn wrote:
> >
> >> Before introduce feature "using". Klp transition will need an
> >> easier way to get klp_ops from klp_func.
> >
> > I think that the patch might make sense on its own as a
> > cleanup/optimization as Petr suggested. If fixed. See below. Then the
> > changelog can be restructured and the above can be removed.
> >
>
> After the previous discuss, maybe this patch of "livepatch: Move struct
> klp_ops to struct klp_func" is useful, while the second patch need to be
> considered later, right?
Yes, but keep them in one set for now, please.
> >> diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
> >> index 51a258c24ff5..d874aecc817b 100644
> >> --- a/include/linux/livepatch.h
> >> +++ b/include/linux/livepatch.h
> >> @@ -22,6 +22,25 @@
> >> #define KLP_TRANSITION_UNPATCHED 0
> >> #define KLP_TRANSITION_PATCHED 1
> >>
> >> +/**
> >> + * struct klp_ops - structure for tracking registered ftrace ops structs
> >> + *
> >> + * A single ftrace_ops is shared between all enabled replacement functions
> >> + * (klp_func structs) which have the same old_func. This allows the switch
> >> + * between function versions to happen instantaneously by updating the klp_ops
> >> + * struct's func_stack list. The winner is the klp_func at the top of the
> >> + * func_stack (front of the list).
> >> + *
> >> + * @node: node for the global klp_ops list
> >> + * @func_stack: list head for the stack of klp_func's (active func is on top)
> >> + * @fops: registered ftrace ops struct
> >> + */
> >> +struct klp_ops {
> >> + struct list_head node;
> >
> > Not needed anymore.
>
> What is not needed any more, do you means the comment?
node member. You removed the global list, hence this member is not needed
anymore.
> >
> >> + struct list_head func_stack;
> >> + struct ftrace_ops fops;
> >> +};
> >> +
> >>
> >> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> >> index 52426665eecc..e4572bf34316 100644
> >> --- a/kernel/livepatch/core.c
> >> +++ b/kernel/livepatch/core.c
> >> @@ -760,6 +760,8 @@ static int klp_init_func(struct klp_object *obj, struct klp_func *func)
> >> if (!func->old_name)
> >> return -EINVAL;
> >>
> >> + func->ops = NULL;
> >> +
> >
> > Any reason why it is not added a couple of lines later alongside the rest
> > of the initialization?
>
> Do you mean I should add couple of lines after 'return -EINVAL' ?
No, I am asking if there is a reason why you added 'func->ops = NULL;'
here and not right after the rest of func initializations
INIT_LIST_HEAD(&func->stack_node);
func->patched = false;
func->transition = false;
> >
> >> /*
> >> * NOPs get the address later. The patched module must be loaded,
> >> * see klp_init_object_loaded().
> >> diff --git a/kernel/livepatch/patch.c b/kernel/livepatch/patch.c
> >> index 90408500e5a3..8ab9c35570f4 100644
> >> --- a/kernel/livepatch/patch.c
> >> +++ b/kernel/livepatch/patch.c
> >> @@ -20,18 +20,25 @@
> >> #include "patch.h"
> >> #include "transition.h"
> >>
> >> -static LIST_HEAD(klp_ops);
> >>
> >> struct klp_ops *klp_find_ops(void *old_func)
> >> {
> >> - struct klp_ops *ops;
> >> + struct klp_patch *patch;
> >> + struct klp_object *obj;
> >> struct klp_func *func;
> >>
> >> - list_for_each_entry(ops, &klp_ops, node) {
> >> - func = list_first_entry(&ops->func_stack, struct klp_func,
> >> - stack_node);
> >> - if (func->old_func == old_func)
> >> - return ops;
> >> + klp_for_each_patch(patch) {
> >> + klp_for_each_object(patch, obj) {
> >> + klp_for_each_func(obj, func) {
> >> + /*
> >> + * Ignore entry where func->ops has not been
> >> + * assigned yet. It is most likely the one
> >> + * which is about to be created/added.
> >> + */
> >> + if (func->old_func == old_func && func->ops)
> >> + return func->ops;
> >> + }
> >> + }
> >> }
> >
> > The function is not used anywhere after this patch.
> >
>
> Maybe there still other places will call this klp_find_ops? Is it safe to delete it?
If you have no other plans with it, then it can be removed since there is
no user after the patch.
Miroslav
next prev parent reply other threads:[~2024-09-06 7:03 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 [this message]
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
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=alpine.LSU.2.21.2409060857130.1385@pobox.suse.cz \
--to=mbenes@suse.cz \
--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=pmladek@suse.com \
--cc=zhangwarden@gmail.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®