;
> This reverts commit 43bd3a95c98e1a86b8b55d97f745c224ecff02b9.
>
> Fixes: 43bd3a95c98e ("kbuild: use -flive-patching when CONFIG_LIVEPATCH is
> enabled")
> Reported-by: Randy Dunlap
> Signed-off-by: Josh Poimboeuf
Acked-by: Miroslav Benes
M
On Thu, 16 Jul 2020, Mark Brown wrote:
> On Thu, Jul 16, 2020 at 01:56:13PM +0200, Miroslav Benes wrote:
> > On Wed, 15 Jul 2020, Mark Brown wrote:
>
> > > -void save_stack_trace(struct stack_trace *trace)
> > > -{
> > > - __save_stack_trace(current,
On Wed, 15 Jul 2020, Mark Brown wrote:
> Currently the callback passed to arch_stack_walk() has an argument called
> reliable passed to it to indicate if the stack entry is reliable, a comment
> says that this is used by some printk() consumers. However in the current
> kernel none of the
Hi,
On Wed, 15 Jul 2020, Mark Brown wrote:
> Historically architectures have had duplicated code in their stack trace
> implementations for filtering what gets traced. In order to avoid this
> duplication some generic code has been provided using a new interface
> arch_stack_walk(), enabled by
On Wed, 15 Jul 2020, Josh Poimboeuf wrote:
> On Wed, Jul 15, 2020 at 03:41:55PM +0200, Petr Mladek wrote:
> > On Wed 2020-07-15 14:10:54, Petr Mladek wrote:
> > > On Wed 2020-07-15 13:11:14, Miroslav Benes wrote:
> > > > Petr, would you agree to revert -flive-patch
On Tue, 14 Jul 2020, Josh Poimboeuf wrote:
> On Tue, Jul 14, 2020 at 12:56:21PM +0200, Miroslav Benes wrote:
> > On Thu, 2 Jul 2020, Josh Poimboeuf wrote:
> >
> > > On Tue, Jun 23, 2020 at 08:06:07AM -0700, Randy Dunlap wrote:
> > > > On 6/22/20 11:28 PM, Step
sions using '-q' option.
>
> Explicitly print the final status on success so that it can be verified
> in the log. The error message is enough on failure.
>
> Reported-by: Kamalesh Babulal
> Signed-off-by: Petr Mladek
Acked-by: Miroslav Benes
M
On Thu, 2 Jul 2020, Josh Poimboeuf wrote:
> On Tue, Jun 23, 2020 at 08:06:07AM -0700, Randy Dunlap wrote:
> > On 6/22/20 11:28 PM, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > Changes since 20200622:
> > >
> >
> > on x86_64:
> >
> > arch/x86/kernel/cpu/mce/core.o: warning: objtool:
On Thu, 18 Jun 2020, Matt Helsley wrote:
> Rather than a standalone executable merge recordmcount as a sub command
> of objtool. This is a small step towards cleaning up recordmcount and
> eventually sharing ELF code with objtool.
>
> For the initial step all that's required is a bit of
Hi,
this is a nice improvement.
> diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
> index 7770edcda3a0..aa0c6d3d2d46 100644
> --- a/tools/objtool/Makefile
> +++ b/tools/objtool/Makefile
> @@ -1,6 +1,7 @@
> # SPDX-License-Identifier: GPL-2.0
> include ../scripts/Makefile.include
>
Hi,
On Fri, 12 Jun 2020, Tobias Klauser wrote:
> Avoid a memory leak in case get_alt_entry returns an error.
yes, this is not the only one, but I doubt we want to spend time on that.
The process is about to exit anyway.
Miroslav
> Signed-off-by: Tobias Klauser
> ---
>
5 add abstraction to handle alternatives
> - Patch 6 adds abstraction to handle jump table
> - Patch 7 abstracts the use of unwind hints. Adding it as RFC as I'm sure
> there's room for improvement.
Reviewed-by: Miroslav Benes
for patches 1-6.
M
Hi Julien,
On Mon, 8 Jun 2020, Julien Thierry wrote:
> Unwind hints are useful to give some information about the call frame
> or stack states in non-standard code.
>
> Despite unwind hints being used in arch-independent code, the
> unwind_hint structure type itself is define in x86 kernel
4.html
> [2] https://lkml.org/lkml/2020/6/4/675
Reviewed-by: Miroslav Benes
M
gt; Signed-off-by: Joe Lawrence
Acked-by: Miroslav Benes
M
Hi,
a nit below...
On Thu, 4 Jun 2020, Julien Thierry wrote:
> One orc_entry is associated with each instruction in the object file,
> but having the orc_entry contained by the instruction structure forces
> architectures not implementing the orc subcommands to provide a dummy
> definition of
Hi,
On Thu, 4 Jun 2020, Max Filippov wrote:
> On configurations with CONFIG_ARCH_HAS_STRICT_MODULE_RWX disabled kernel
> build fails with the following message:
>
> kernel/module.c:3593:2: error: implicit declaration of function
> ‘module_enable_ro’;
>
> Add empty module_enable_ro
Hi,
I'm confused...
On Wed, 3 Jun 2020, Cheng Jian wrote:
> When lookup the symbols of module by module_kallsyms_lookup_name(),
> the symbols address is visible only if the module's status isn't
> MODULE_STATE_UNFORMED, This is problematic.
>
> When complete_formation is done, the state of the
On Tue, 26 May 2020, Josh Poimboeuf wrote:
> On Mon, May 25, 2020 at 01:07:27PM +0200, Miroslav Benes wrote:
> > > I'll try to find out which optimization does this, because it is a
> > > slightly different scenario than hiding __noreturn from the callees.
> > >
> I'll try to find out which optimization does this, because it is a
> slightly different scenario than hiding __noreturn from the callees.
> Probably -fno-ipa-pure-const again.
And it is indeed -fno-ipa-pure-const again.
Miroslav
On Thu, 21 May 2020, Randy Dunlap wrote:
> On 5/21/20 7:12 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20200519:
> >
These are indeed caused by -flive-patching
> on x86_64:
>
> fs/open.o: warning: objtool: chmod_common()+0x104: unreachable instruction
> fs/namei.o:
inder/orc: Dont bail on stack overflow")
> Fixes: 98d0c8ebf77e ("x86/unwind/orc: Prevent unwinding before ORC
> initialization")
> Reported-by: Pavel Machek
> Signed-off-by: Josh Poimboeuf
Reviewed-by: Miroslav Benes
M
On Fri, 15 May 2020, Kamalesh Babulal wrote:
> Add lib/livepatch to list of livepatching F: patterns in MAINTAINERS.
>
> Suggested-by: Jiri Kosina
> Signed-off-by: Kamalesh Babulal
Acked-by: Miroslav Benes
M
>
> Signed-off-by: Kamalesh Babulal
Acked-by: Miroslav Benes
M
On Fri, 8 May 2020, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the livepatching tree got a conflict in:
>
> kernel/module.c
>
> between commits:
>
> db991af02f11 ("module: break nested ARCH_HAS_STRICT_MODULE_RWX and
> STRICT_MODULE_RWX #ifdefs")
> 5c3a7db0c7ec
On Tue, 5 May 2020, Thomas Gleixner wrote:
> Make sure task_work runs before any kind of userspace -- very much
> including signals -- is invoked.
I might be missing something, but isn't this guaranteed by
do_signal()->get_signal()->task_work_run() path?
Miroslav
The following commit has been merged into the objtool/core branch of tip:
Commit-ID: b490f45362002fef57996388e395efc974b013f4
Gitweb:
https://git.kernel.org/tip/b490f45362002fef57996388e395efc974b013f4
Author:Miroslav Benes
AuthorDate:Fri, 24 Apr 2020 16:30:42 +02:00
ce this patch is separate from the rest and it's based on
> modules-next, I can just take this last patch through the modules tree.
It depends on 8/11 of the series.
Acked-by: Miroslav Benes
for the patch.
M
on for them, which
> in turn means we can now unwind through a retpoline.
>
> New since last time:
>
> - 1-3, alternatives vs ORC unwind
> - 7-9: implement some suggestions from Julien
> - addressed feedback
You can add my
Reviewed-by: Miroslav Benes
to patches 1A, 1B and
On Wed, 29 Apr 2020, Peter Zijlstra wrote:
> On Wed, Apr 29, 2020 at 04:33:31PM +0200, Miroslav Benes wrote:
> > On Tue, 28 Apr 2020, Peter Zijlstra wrote:
> > > /*
> > > + * Alternatives should not contain any ORC entries, this in turn means
> > > they
>
On Tue, 28 Apr 2020, Peter Zijlstra wrote:
> Jann reported that (for instance) entry_64.o:general_protection has
> very odd ORC data:
>
> 0f40 :
> ###sp:sp+8 bp:(und) type:iret end:0
> f40: 90 nop
> ###sp:(und) bp:(und) type:call end:0
>
| 177 +++---
> kernel/module.c | 23 +--
> 12 files changed, 277 insertions(+), 228 deletions(-)
> delete mode 100644 arch/x86/kernel/livepatch.c
With the small issue in patch 2 fixed
Acked-by: Miroslav Benes
Great stuff. I am happy we will get rid of the arch-specific code.
M
> @@ -738,18 +765,23 @@ static int klp_init_object_loaded(struct klp_patch
> *patch,
> int ret;
>
> mutex_lock(_mutex);
> -
> module_disable_ro(patch->mod);
> - ret = klp_write_object_relocations(patch->mod, obj);
> - if (ret) {
> -
On Tue, 22 Oct 2019, Josh Poimboeuf wrote:
> On Tue, Oct 22, 2019 at 10:27:49AM +0200, Miroslav Benes wrote:
> > > Does that sound like what you had in mind or am I totally off?
> >
> > Sort of. What I had in mind was that we could get rid of all special .klp
> >
On Wed, 16 Oct 2019, Peter Zijlstra wrote:
> On Wed, Oct 16, 2019 at 08:51:27AM +0200, Miroslav Benes wrote:
> > On Tue, 15 Oct 2019, Joe Lawrence wrote:
> >
> > > On 10/15/19 10:13 AM, Miroslav Benes wrote:
> > > > Yes, it does. klp_module_comin
On Fri, 18 Oct 2019, Jessica Yu wrote:
> +++ Miroslav Benes [16/10/19 15:29 +0200]:
> >On Wed, 16 Oct 2019, Miroslav Benes wrote:
> >
> >> On Wed, 16 Oct 2019, Peter Zijlstra wrote:
> >>
> >> > On Tue, Oct 15, 2019 at 06:27:05PM -0400, Steven Roste
On Wed, 16 Oct 2019, Steven Rostedt wrote:
> On Wed, 16 Oct 2019 13:33:12 +0200
> Miroslav Benes wrote:
>
> > Livepatch uses ftrace for redirection to new patched functions. It means
> > that if ftrace is disabled, all live patched functions are disabled as
>
On Wed, 16 Oct 2019, Miroslav Benes wrote:
> On Wed, 16 Oct 2019, Peter Zijlstra wrote:
>
> > On Tue, Oct 15, 2019 at 06:27:05PM -0400, Steven Rostedt wrote:
> >
> > > (7) Seventh session, titled "klp-convert and livepatch relocations", was
> > &g
From: Joe Lawrence
Livepatch selftests currently save the current dynamic debug config and
tweak it for the selftests. The config is restored at the end. Make the
infrastructure generic, so that more variables can be saved and
restored.
Signed-off-by: Joe Lawrence
Signed-off-by: Miroslav Benes
nvironment
configuration that is saved and restored when running the selftests.
Signed-off-by: Joe Lawrence
Signed-off-by: Miroslav Benes
---
tools/testing/selftests/livepatch/Makefile| 3 +-
.../testing/selftests/livepatch/functions.sh | 14 +++-
.../selftests/livepatch/test-ftrace.sh
-by: Miroslav Benes
Reviewed-by: Petr Mladek
Reviewed-by: Kamalesh Babulal
---
Documentation/trace/ftrace-uses.rst | 8
Documentation/trace/ftrace.rst | 4 +++-
include/linux/ftrace.h | 3 +++
kernel/livepatch/patch.c| 3 ++-
kernel/trace/ftrace.c
action with ftrace_enabled
Miroslav Benes (1):
ftrace: Introduce PERMANENT ftrace_ops flag
Documentation/trace/ftrace-uses.rst | 8 +++
Documentation/trace/ftrace.rst| 4 +-
include/linux/ftrace.h| 3 +
kernel/livepatch/patch.c
On Wed, 16 Oct 2019, Peter Zijlstra wrote:
> On Tue, Oct 15, 2019 at 06:27:05PM -0400, Steven Rostedt wrote:
>
> > (7) Seventh session, titled "klp-convert and livepatch relocations", was led
> > by Joe Lawrence.
> >
> > Joe started the session with problem statement: accessing non exported /
On Wed, 16 Oct 2019, Peter Zijlstra wrote:
> > which are not compatible with livepatching. GCC upstream now has
> > -flive-patching option, which disables all those interfering optimizations.
>
> Which, IIRC, has a significant performance impact and should thus really
> not be used...
On Tue, 15 Oct 2019, Joe Lawrence wrote:
> On 10/15/19 10:13 AM, Miroslav Benes wrote:
> > Yes, it does. klp_module_coming() calls module_disable_ro() on all
> > patching modules which patch the coming module in order to call
> > apply_relocate_add(). New (patching)
[ live-patching ML CCed ]
On Tue, 15 Oct 2019, Peter Zijlstra wrote:
> On Tue, Oct 15, 2019 at 03:07:40PM +0200, Jessica Yu wrote:
>
> > > The fact that it is executable; also the fact that you do it right after
> > > we mark it ro. Flipping the memory protections back and forth is just
> > >
On Tue, 15 Oct 2019, Joe Lawrence wrote:
> On 10/15/19 7:23 AM, Miroslav Benes wrote:
> >> Hi Miroslav,
> >>
> >> Maybe we should add a test to verify this new behavior? See sample
> >> version below (lightly tested). We can add to this one,
> Hi Miroslav,
>
> Maybe we should add a test to verify this new behavior? See sample
> version below (lightly tested). We can add to this one, or patch
> seperately if you prefer.
Thanks a lot, Joe. It looks nice. I'll include it in v3. One question
below.
> -->8-- -->8-- -->8-- -->8--
On Tue, 15 Oct 2019, Petr Mladek wrote:
> On Mon 2019-10-14 11:17:19, Steven Rostedt wrote:
> > On Mon, 14 Oct 2019 12:59:23 +0200
> > Miroslav Benes wrote:
> >
> > > int
> > > ftrace_enable_sysctl(struct ctl_table *table, int write,
> > >
-by: Miroslav Benes
---
v1->v2:
- different logic, proposed by Joe Lawrence
Two things I am not sure about much:
- return codes. I chose EBUSY, because it seemed the least
inappropriate. I usually pick the wrong one, so suggestions are
welcome.
- I did not add any pr_* reporting the prob
On Thu, 10 Oct 2019, Steven Rostedt wrote:
> On Thu, 10 Oct 2019 10:50:35 +0200
> Petr Mladek wrote:
>
> > It will make the flag unusable for other ftrace users. But it
> > will be already be the case when it can't be disabled.
>
> Honestly, I hate that flag. Most people don't even know about
On Tue, 8 Oct 2019, Steven Rostedt wrote:
> On Tue, 8 Oct 2019 15:35:34 -0400
> Joe Lawrence wrote:
>
> >
> > I wonder if the opposite would be more intuitive: when ftrace_enabled is
> > not set, don't allow livepatches to register ftrace filters and
> > likewise, don't allow ftrace_enabled to
On Mon, 7 Oct 2019, Peter Zijlstra wrote:
> Now that notifiers got unbroken; use the proper interface to handle
> notifier errors and propagate them.
>
> There were already MODULE_STATE_COMING notifiers that failed; notably:
>
> - jump_label_module_notifier()
> - tracepoint_module_notify()
>
Function test_rec_ops_needs_regs() tests whether ftrace_ops registered
on a record needs saved regs. That is, it tests for
FTRACE_OPS_FL_SAVE_REGS being set.
The same logic will be reused for newly introduced
FTRACE_OPS_FL_PERMANENT flag, so make the function generic.
Signed-off-by: Miroslav
, but it still may be surprising.
Introduce PERMANENT ftrace_ops flag to amend this. If the
FTRACE_OPS_FL_PERMANENT is set, the tracing of the function is not
disabled. Such ftrace_ops can still be unregistered in a standard way.
The patch set passes ftrace and livepatch kselftests.
Miroslav Benes (3
Use FTRACE_OPS_FL_PERMANENT flag to be immune to toggling the
'ftrace_enabled' sysctl knob.
Signed-off-by: Miroslav Benes
---
kernel/livepatch/patch.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/livepatch/patch.c b/kernel/livepatch/patch.c
index bd43537702bd
, but it still may be surprising.
Introduce PERMANENT ftrace_ops flag to amend this. If the
FTRACE_OPS_FL_PERMANENT is set, the tracing of the function is not
disabled. Such ftrace_ops can still be unregistered in a standard way.
Signed-off-by: Miroslav Benes
---
Documentation/trace/ftrace-uses.rst
On Wed, 2 Oct 2019, Josh Poimboeuf wrote:
> On Thu, Sep 05, 2019 at 02:45:12PM +0200, Miroslav Benes wrote:
> > Josh reported a bug:
> >
> > When the object to be patched is a module, and that module is
> > rmmod'ed and reloaded, it fails to load with:
>
On Wed, 2 Oct 2019, Petr Mladek wrote:
> On Thu 2019-09-05 14:45:14, Miroslav Benes wrote:
> > Signed-off-by: Miroslav Benes
>
> This might depend on personal preferences.
True.
> What was the motivation
> for this patch, please? Did it just follow some common
> style
On Wed, 2 Oct 2019, Petr Mladek wrote:
> On Thu 2019-09-05 14:45:12, Miroslav Benes wrote:
> > We thus decided to reverse the relocation patching (clear all relocation
> > targets on x86_64, or return back nops on powerpc). The solution is not
> > universal and is t
On Thu, 5 Sep 2019, Miroslav Benes wrote:
> Updated version with Petr's feedback. It looks a bit different and
> better now (I would say). Not that it should be considered before we
> decide what to do with late module patching, but I finished it before
> the discussion started and s
> --- a/include/linux/entry-common.h
> +++ b/include/linux/entry-common.h
[...]
> +#define EXIT_TO_GUESTMODE_WORK
> \
> + (_TIF_NEED_RESCHED | _TIF_SIGPENDING | _TIF_NOTIFY_RESUME | \
> + ARCH_EXIT_TO_GUESTMODE_WORK)
[...]
> ---
> > Now, I don't think that replacing .ko on disk is a good idea. We've
> > already discussed it. It would lead to a maintenance/packaging problem,
> > because you never know which version of the module is loaded in the
> > system. The state space grows rather rapidly there.
>
> What exactly
On Thu, 5 Sep 2019, Josh Poimboeuf wrote:
> On Thu, Sep 05, 2019 at 02:03:34PM +0200, Miroslav Benes wrote:
> > > > + I would like to better understand the scope of the current
> > > > problems. It is about modifying code in the livepatch that
> > > >
Functions klp_write_object_relocations() and
klp_clear_object_relocations() share a lot of code. Take the code out to
a common function and provide the specific actions through callbacks.
Signed-off-by: Miroslav Benes
---
kernel/livepatch/core.c | 84 +
1
/20190719122840.15353-1-mbe...@suse.cz
Tested on x86_64, ppc64le and s390x. Cross-compiled on arm64 to verify
that nothing is broken.
[1] 20180602161151.apuhs2dygsexmcg2@treble
[2] 1561019068-132672-1-git-send-email-cj.chengj...@huawei.com
[3] 20180607092949.1706-1-mbe...@suse.cz
Miroslav Benes (3
Signed-off-by: Miroslav Benes
---
kernel/livepatch/core.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
index 023c9333c276..73d5add5 100644
--- a/kernel/livepatch/core.c
+++ b/kernel/livepatch/core.c
@@ -251,7
us decided to reverse the relocation patching (clear all relocation
targets on x86_64, or return back nops on powerpc). The solution is not
universal and is too much arch-specific, but it may prove to be simpler
in the end.
Reported-by: Josh Poimboeuf
Signed-off-by: Miroslav Benes
---
arch/powe
On Wed, 4 Sep 2019, Josh Poimboeuf wrote:
> On Tue, Sep 03, 2019 at 03:02:34PM +0200, Miroslav Benes wrote:
> > On Mon, 2 Sep 2019, Joe Lawrence wrote:
> >
> > > On 9/2/19 12:13 PM, Miroslav Benes wrote:
> > > >> I can easily foresee more pr
On Wed, 4 Sep 2019, Josh Poimboeuf wrote:
> On Wed, Sep 04, 2019 at 10:49:32AM +0200, Petr Mladek wrote:
> > On Tue 2019-09-03 15:02:34, Miroslav Benes wrote:
> > > On Mon, 2 Sep 2019, Joe Lawrence wrote:
> > >
> > > > On 9/2/19 12:13 PM, Miroslav Benes
[...]
> I wonder what is necessary for a productive discussion on Plumbers:
[...]
> + It might be useful to prepare overview of the existing proposals
> and agree on the positives and negatives. I am afraid that some
> of them might depend on the customer base and
> use
On Mon, 2 Sep 2019, Joe Lawrence wrote:
> On 9/2/19 12:13 PM, Miroslav Benes wrote:
> >> I can easily foresee more problems like those in the future. Going
> >> forward we have to always keep track of which special sections are
> >> needed for which architecture
> I can easily foresee more problems like those in the future. Going
> forward we have to always keep track of which special sections are
> needed for which architectures. Those special sections can change over
> time, or can simply be overlooked for a given architecture. It's
> fragile.
Hi,
On Mon, 19 Aug 2019, Jisheng Zhang wrote:
> On some arch, the FTRACE_WITH_REGS is implemented with gcc's
> -fpatchable-function-entry (=2), gcc adds 2 NOPs at the beginning
> of each function, so this makes the MCOUNT_ADDR useless. In ftrace
> common framework, MCOUNT_ADDR is mostly used to
> > How is this feature supposed to work for external modules?
> >
> > klp-convert receives:
> > "symbols from vmlinux" + "symbols from no-klp in-tree modules"
> > + "symbols from no-klp external modules" ??
> >
>
> I don't think that this use-case has been previously thought out (Miroslav,
>
On Mon, 19 Aug 2019, Masahiro Yamada wrote:
> On Fri, Aug 16, 2019 at 9:43 PM Joe Lawrence wrote:
> >
> > On 8/16/19 4:19 AM, Miroslav Benes wrote:
> > > Hi,
> > >
> > >> I cleaned up the build system, and pushed it based on my
> > >>
Hi,
> I cleaned up the build system, and pushed it based on my
> kbuild tree.
>
> Please see:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild.git
> klp-cleanup
This indeed looks much simpler and cleaner (as far as I can judge with my
limited kbuild knowledge). We just
On Mon, 22 Jul 2019, Petr Mladek wrote:
> On Fri 2019-07-19 14:28:40, Miroslav Benes wrote:
> > Josh reported a bug:
> >
> > When the object to be patched is a module, and that module is
> > rmmod'ed and reloaded, it fails to load with:
> >
> >
On Sun, 28 Jul 2019, Josh Poimboeuf wrote:
> On Fri, Jul 19, 2019 at 02:28:40PM +0200, Miroslav Benes wrote:
> > Josh reported a bug:
> >
> > When the object to be patched is a module, and that module is
> > rmmod'ed and reloaded, it fails to load with:
>
> > diff --git a/arch/s390/include/asm/unwind.h b/arch/s390/include/asm/unwind.h
> > index d827b5b9a32c..1cc96c54169c 100644
> > --- a/arch/s390/include/asm/unwind.h
> > +++ b/arch/s390/include/asm/unwind.h
> > @@ -45,6 +45,25 @@ void __unwind_start(struct unwind_state *state, struct
> >
On Sun, 28 Jul 2019, Josh Poimboeuf wrote:
> On Wed, Jul 17, 2019 at 01:01:27PM +0200, Miroslav Benes wrote:
> > > On a related note, do you think it would be feasible to extend (in
> > > another patchset) the reliable stack unwinding code a bit so that we
> > >
logic in klp_is_state_compatible() [Miroslav]
> + Document how livepatches should handle the state [Nicolai]
> + Fix some typos, formulation, module metadata [Joe, Miroslav]
I noticed couple of typos along the way but apart from that
Acked-by: Miroslav Benes
Miroslav
On Fri, 19 Jul 2019, Petr Mladek wrote:
> Documentation explaining the motivation, capabilities, and usage
> of the new API for tracking system state changes.
>
> Signed-off-by: Petr Mladek
> ---
> Documentation/livepatch/index.rst| 1 +
> Documentation/livepatch/system-state.rst |
> diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
> index 9c8b637f17cd..bc5766f45442 100644
> --- a/include/linux/livepatch.h
> +++ b/include/linux/livepatch.h
> @@ -133,10 +133,12 @@ struct klp_object {
> /**
> * struct klp_state - state of the system modified by the
On Fri, 19 Jul 2019, Petr Mladek wrote:
> This is another step how to help maintaining more livepatches.
>
> One big help was the atomic replace and cumulative livepatches. These
> livepatches replace the already installed ones. Therefore it should
> be enough when each cumulative livepatch is
On Fri, 19 Jul 2019, Petr Mladek wrote:
> Pre/post (un)patch callbacks might manipulate the system state. Cumulative
> livepatches might need to take over the changes made by the replaced
> ones. For this they might need to access some data stored or referenced
> by the old livepatches.
>
>
On Wed, 31 Jul 2019, Masahiro Yamada wrote:
> Hi Joe,
>
>
> On Thu, May 9, 2019 at 11:39 PM Joe Lawrence wrote:
> >
> > From: Miroslav Benes
> >
> > Currently, livepatch infrastructure in the kernel relies on
> > MODULE_INFO(livepatch, "Y")
welcome
Lightly tested on both x86_64 and ppc64le and it looked ok.
[1] 20180602161151.apuhs2dygsexmcg2@treble
[2] 1561019068-132672-1-git-send-email-cj.chengj...@huawei.com
[3] 20180607092949.1706-1-mbe...@suse.cz
Miroslav Benes (2):
livepatch: Nullify obj->mod in klp_module_coming()'s er
gt;mod variable and could currently give a
wrong return value. The bug is probably harmless as of now.
Signed-off-by: Miroslav Benes
Reviewed-by: Petr Mladek
---
kernel/livepatch/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
us decided to reverse the relocation patching (clear all relocation
targets on x86_64, or return back nops on powerpc). The solution is not
universal and is too much arch-specific, but it may prove to be simpler
in the end.
Reported-by: Josh Poimboeuf
Signed-off-by: Miroslav Benes
---
arch/powe
On Tue, 16 Jul 2019, Joe Lawrence wrote:
> On Wed, Jul 10, 2019 at 12:59:18PM +0200, Miroslav Benes wrote:
> > The livepatch consistency model requires reliable stack tracing
> > architecture support in order to work properly. In order to achieve
> > this, two main issues hav
t considered to be a stack corruption.
Signed-off-by: Miroslav Benes
---
- based on Linus' master
- passes livepatch kselftests
- passes tests from https://github.com/lpechacek/qa_test_klp, which
stress the consistency model and the unwinder a bit more
arch/s390/Kconfig | 1 +
> is implemented for arm or nds32. These architectures call
> set_all_modules_text_rw() and use stop_machine() at the same time.
>
> Fixes: 9f255b632bf12c4dd7 ("module: Fix livepatch/ftrace module text
> permissions race")
> Signed-off-by: Petr Mladek
Reported-by: Mir
On Tue, 25 Jun 2019, Joe Lawrence wrote:
> On Tue, Jun 25, 2019 at 01:36:37PM +0200, Miroslav Benes wrote:
> >
> > [ ... snip ... ]
> >
> > If I revert commit d59cadc0a8f8 ("[squash] klp-convert: make
> > convert_rela() list-safe") (from Joe's expand
tching
> > operations -- and their respective permissions changes -- are protected
> > by the text_mutex.
> >
> > Reported-by: Johannes Erdfelt
> > Fixes: 444d13ff10fb ("modules: add ro_after_init support")
> > Signed-off-by: Josh Poimboeuf
> &g
On Fri, 14 Jun 2019, Petr Mladek wrote:
> On Thu 2019-06-13 16:48:02, Joe Lawrence wrote:
> > On 6/13/19 9:15 AM, Joe Lawrence wrote:
> > > On 6/13/19 9:00 AM, Miroslav Benes wrote:
> > >> Hi Joe,
> > >>
> > >> first, I'm sorry for the lack
On Sat, 22 Jun 2019, Thomas Gleixner wrote:
> Miroslav,
>
> On Thu, 20 Jun 2019, Miroslav Benes wrote:
> > On Thu, 20 Jun 2019, Cheng Jian wrote:
> >
> > > This reverts commit eda9cec4c9a12208a6f69fbe68f72a6311d50032.
> > >
> > > Since commit (e
> diff --git a/lib/livepatch/test_klp_state.c b/lib/livepatch/test_klp_state.c
> new file mode 100644
> index ..c43dc2f2e01d
> --- /dev/null
> +++ b/lib/livepatch/test_klp_state.c
> @@ -0,0 +1,161 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2019 SUSE
> +
> +#define
> +/* Check if the patch is able to deal with the given system state. */
> +static bool klp_is_state_compatible(struct klp_patch *patch,
> + struct klp_state *state)
> +{
> + struct klp_state *new_state;
> +
> + new_state = klp_get_state(patch, state->id);
>
On Thu, 20 Jun 2019, Cheng Jian wrote:
> This reverts commit eda9cec4c9a12208a6f69fbe68f72a6311d50032.
>
> Since commit (eda9cec4c9a1 'x86/module: Detect and skip invalid
> relocations') add some sanity check in apply_relocate_add, borke
> re-insmod a kernel module which has been patched before,
101 - 200 of 1277 matches
Mail list logo
