From: Petr Mladek <pmladek@suse.com>
To: zhang warden <zhangwarden@gmail.com>
Cc: Josh Poimboeuf <jpoimboe@kernel.org>,
Miroslav Benes <mbenes@suse.cz>, Jiri Kosina <jikos@kernel.org>,
Joe Lawrence <joe.lawrence@redhat.com>,
live-patching@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v4 2/2] livepatch: Add using attribute to klp_func for using function show
Date: Fri, 6 Sep 2024 18:39:56 +0200 [thread overview]
Message-ID: <ZtswXFD3xud0i6AO@pathway.suse.cz> (raw)
In-Reply-To: <285979BA-2A85-495F-8888-47EAFC061BE9@gmail.com>
On Fri 2024-09-06 17:39:46, zhang warden wrote:
> Hi, John & Miroslav
>
> >>
> >> Would it be possible to just use klp_transition_patch and implement the
> >> logic just in using_show()?
> >
> > Yes, containing the logic to the sysfs file sounds a lot better.
>
> Maybe I can try to use the state of klp_transition_patch to update the function's state instead of changing code in klp_complete_transition?
>
> >
> >> I have not thought through it completely but
> >> klp_transition_patch is also an indicator that there is a transition going
> >> on. It is set to NULL only after all func->transition are false. So if you
> >> check that, you can assign -1 in using_show() immediately and then just
> >> look at the top of func_stack.
> >
> > sysfs already has per-patch 'transition' and 'enabled' files so I don't
> > like duplicating that information.
> >
> > The only thing missing is the patch stack order. How about a simple
> > per-patch file which indicates that?
> >
> > /sys/kernel/livepatch/<patchA>/order => 1
> > /sys/kernel/livepatch/<patchB>/order => 2
> >
> > The implementation should be trivial with the use of
> > klp_for_each_patch() to count the patches.
> >
> I think this is the second solution. It seems that adding an
> interface to patch level is an acceptable way.
It seems to be the only acceptable idea at the moment.
> And if patch order
> is provided in /sys/kernel/livepatch/<patchA>/order, we should
> make a user space tool to calculate the function that
> is activate in the system. From my point to the original
> problem, it is more look like a workaround.
It is always a compromise between the complexity and the benefit.
Upstream will accept only changes which are worth it.
Here, the main problem is that you do not have coordinated developement
and installation of livepatches. This is dangerous and you should
not do it! Upstream will never support such a wild approach.
You could get upstream some features which would make your life
easier. But the features must be worth the effort.
Best Regards,
Petr
next prev parent reply other threads:[~2024-09-06 16:40 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 [this message]
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=ZtswXFD3xud0i6AO@pathway.suse.cz \
--to=pmladek@suse.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=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;
as well as URLs for NNTP newsgroup(s).