On 01/30/2018 01:19 PM, Jason Baron wrote:
> [ ... snip ... ]
>
> Our main interest in 'atomic replace' is simply to make sure that
> cumulative patches work as expected in that they 'replace' any prior
> patches. We have an interest primarily in being able to apply patches
> from the stable trees
On 01/30/2018 09:03 AM, Petr Mladek wrote:
> On Fri 2018-01-26 14:29:36, Evgenii Shatokhin wrote:
>>
>> In my experience, it was quite convenient sometimes to just "replace all
>> binary patches the user currently has loaded with this single one". No
>> matter what these original binary patches
On 01/25/2018 11:01 AM, Petr Mladek wrote:
> We are going to add a feature called atomic replace. It will allow to
> create a patch that would replace all already registered patches.
> For this, we will need to dynamically create funcs' and objects'
> for functions that are not longer patched.
On 02/01/2018 08:49 AM, Miroslav Benes wrote:
>
> Well, one more thing. I think there is a problem with shadow variables.
> Similar to callbacks situation. Shadow variables cannot be destroyed the
> way it is shown in our samples. Cumulative patches want to preserve
> everything as much as
Hi Davidlohr,
I was looking into backporting commit 95e91b831f87 ("ipc/shm: Fix shmat
mmap nil-page protection") to a distro kernel and Andrea brought up some
interesting questions about that change.
We saw that a LTP test [1] was added some time ago to reproduce behavior
matching that of the
, gfp);
>
> /* Attach a corresponding shadow variable, then initialize it */
> - ps_lock = klp_shadow_alloc(sta, PS_LOCK, NULL, sizeof(ps_lock), gfp);
> + ps_lock = klp_shadow_alloc(sta, PS_LOCK, NULL, sizeof(*ps_lock), gfp);
> if (!ps_lock)
> goto shadow_fail;
> spin_lock_init(ps_lock);
> --
> 1.8.5.6
Thanks, Petr!
Acked-by: Joe Lawrence
-- Joe
ng the
new value from the user buffer, verifying bounds, and calling
round_pipe_size() with a single assignment to pipe_max_size.
Reported-by: Mikulas Patocka
Signed-off-by: Joe Lawrence
---
fs/pipe.c | 16 ++--
include/linux/pipe_fs_i.h | 1 +
include/linux/sysctl
n == 0 and updates its callers
to handle accordingly.
Reported-by: Mikulas Patocka
Signed-off-by: Joe Lawrence
---
fs/pipe.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/fs/pipe.c b/fs/pipe.c
index a21ad26de557..8cbc97d97753 100644
--- a/fs/pipe.c
+++ b/
s/fs/pipe-max-size
-2147483648
Use unsigned operations on this variable to avoid such negative values.
Reported-by: Mikulas Patocka
Signed-off-by: Joe Lawrence
---
fs/pipe.c | 2 +-
kernel/sysctl.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/pipe.c b/fs
0.042s
- Before: found a non-rounded value within a few minutes
- After: never encountered a non-page-rounded value
Joe Lawrence (3):
pipe: match pipe_max_size data type with procfs
pipe: avoid round_pipe_size() nr_pages overflow on 32-bit
pipe: add proc_dopipe_max_size()
On 09/26/2017 10:49 AM, Petr Mladek wrote:
> On Thu 2017-08-31 10:53:51, Joe Lawrence wrote:
>> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
>> index b9628e43c78f..aca62c4b8616 100644
>> --- a/kernel/livepatch/core.c
>> +++ b/kernel/livepatch/core.c
&
On 09/27/2017 07:49 AM, Petr Mladek wrote:
> On Thu 2017-08-31 10:53:53, Joe Lawrence wrote:
>> Log a few kernel debug messages at the beginning of the following livepatch
>> transition functions:
>>
>> klp_complete_transition()
>> klp_cancel_tran
bject(patch, obj)
> - if (patch->enabled && obj->patched)
> + if (obj->patched)
> klp_pre_unpatch_callback(obj);
>
> /*
> --
> 1.8.5.6
Looks reasonable to me and cleans up the klp_pre_unpatch_callback()
calling condition.
Acked-by: Joe Lawrence
_going() code. But I think
> that it is cleaner this way. For example, someone
> might later decide to call the callback only when
> obj->patched flag is set.
JL: (Moved up above.)
>
> Finally, I used this opportunity to make klp_pre_patch_callback()
> more readable.
JL: Agre
[ fixed jeyu's email address ]
On 5/20/19 3:49 PM, Johannes Erdfelt wrote:
[ ... snip ... ]
I have put together a test case that can reproduce the crash using
KVM. The tarball includes a minimal kernel and initramfs, along with
a script to run qemu and the .config used to build the kernel. By
On 5/20/19 5:09 PM, Johannes Erdfelt wrote:
On Mon, May 20, 2019, Joe Lawrence wrote:
[ fixed jeyu's email address ]
Thank you, the bounce message made it seem like my mail server was
blocked and not that the address didn't exist.
I think MAINTAINERS needs an update since it still has
On 5/20/19 5:19 PM, Joe Lawrence wrote:
On 5/20/19 5:09 PM, Johannes Erdfelt wrote:
On Mon, May 20, 2019, Joe Lawrence wrote:
These two testing scenarios might be interesting to add to our selftests
suite. Can you post or add the source(s) to livepatch-test.ko to the
tarball?
I made
_ unknown tracepoint
Error: File /sys/kernel/debug/tracing/events/probe/cmdline_proc_show not found.
Hint: Perhaps this kernel misses some CONFIG_ setting to enable this feature?.
Run 'perf list' for a list of valid events
Usage: perf record [] []
or: perf record [] -- []
-e, --eventevent selector. use 'perf list' to list available
events
These results reflect my underestanding of FTRACE_OPS_FL_IPMODIFY in
light of your changes, so feel free to add my:
Acked-by: Joe Lawrence
-- Joe
On 6/25/19 7:36 AM, Miroslav Benes wrote:
> [ ... snip ... ]
>
So I made a couple of experiments and found that GCC is somehow involved.
If klp-convert (from scripts/livepatch/) is compiled with our GCC 4.8.5
from SLE12, the output is incorrect. If I compile it with GCC 7.4.0 from
openSUSE
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 expanded github tree), the problem
> disappears.
>
> I haven't spotted any problem in the code and I cannot
ate module
patching.
Hi Miroslav,
I was tinkering with the "blue-sky" ideas that I mentioned to Josh the
other day. I dunno if you had a chance to look at what removing that
code looks like, but I can continue to flesh out that idea if it looks
interesting:
https://github.com/joe-lawr
On 8/14/19 7:16 AM, Anders Roxell wrote:
When generating config with 'make defconfig kselftest-merge' fragment
CONFIG_TEST_LIVEPATCH=m isn't set.
Rework to enable CONFIG_LIVEPATCH and CONFIG_DYNAMIC_DEBUG as well.
Signed-off-by: Anders Roxell
---
tools/testing/selftests/livepatch/config | 2
state.c
> create mode 100644 lib/livepatch/test_klp_state2.c
> create mode 100644 lib/livepatch/test_klp_state3.c
> create mode 100755 tools/testing/selftests/livepatch/test-state.sh
>
> --
> 2.16.4
>
Hi Petr,
Thanks for respinning this one with the latest updates. The
implementation looks fine to me. I have two really minor nits for the
selftest (I'll reply to that commit), but I wouldn't hold up the series
for them.
Acked-by: Joe Lawrence
-- Joe
ivepatch/test-state.sh
> @@ -0,0 +1,180 @@
> +#!/bin/bash
> +# SPDX-License-Identifier: GPL-2.0
> +# Copyright (C) 2018 Joe Lawrence
> +
nit: this should probably read as:
# Copyright (C) 2019 Petr Mladek
> +. $(dirname $0)/functions.sh
> +
> +MOD_LIVEPATCH=test_klp
On 8/26/19 10:54 AM, Josh Poimboeuf wrote:
On Fri, Aug 23, 2019 at 10:13:06AM +0200, Petr Mladek wrote:
On Thu 2019-08-22 17:36:49, Josh Poimboeuf wrote:
On Fri, Aug 16, 2019 at 11:46:08AM +0200, Petr Mladek wrote:
On Wed 2019-08-14 10:12:44, Josh Poimboeuf wrote:
On Wed, Aug 14, 2019 at
On Wed, Jul 31, 2019 at 12:36:05PM +0900, Masahiro Yamada wrote:
> On Wed, Jul 31, 2019 at 11:50 AM Masahiro Yamada
> wrote:
> >
> > On Thu, May 9, 2019 at 11:39 PM Joe Lawrence
> > wrote:
> > >
> > > From: Josh Poimboeuf
> > >
> > >
On Wed, Jul 31, 2019 at 02:58:27PM +0900, 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(livep
On Mon, Oct 07, 2019 at 10:17:11AM +0200, Miroslav Benes wrote:
> Livepatch uses ftrace for redirection to new patched functions. It is
> thus directly affected by ftrace sysctl knobs such as ftrace_enabled.
> Setting ftrace_enabled to 0 also disables all live patched functions. It
> is not a
On Wed, Oct 09, 2019 at 01:22:34PM +0200, Petr Mladek wrote:
> On Tue 2019-10-08 15:35:34, Joe Lawrence wrote:
> > On Mon, Oct 07, 2019 at 10:17:11AM +0200, Miroslav Benes wrote:
> > > Livepatch uses ftrace for redirection to new patched functions. It is
> > > thus
On Wed, Oct 09, 2019 at 04:18:59PM +0200, Petr Mladek wrote:
> On Fri 2019-10-04 10:47:42, Joe Lawrence wrote:
> > On Thu, Oct 03, 2019 at 11:01:37AM +0200, Petr Mladek wrote:
> > > Four selftests for the new API.
> > >
> > > --- /dev/null
> > >
On 10/16/19 1:10 PM, Kamalesh Babulal wrote:
On 10/16/19 5:03 PM, Miroslav Benes wrote:
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
On 10/16/19 1:06 PM, Kamalesh Babulal wrote:
On 10/16/19 5:03 PM, Miroslav Benes wrote:
From: Joe Lawrence
Since livepatching depends upon ftrace handlers to implement "patched"
code functionality, verify that the ftrace_enabled sysctl value
interacts with livepatch registration a
On Thu, Apr 23, 2020 at 01:10:30PM -0500, Josh Poimboeuf wrote:
> On Thu, Apr 23, 2020 at 09:12:28AM -0500, Josh Poimboeuf wrote:
> > > > this is strange. While I would have expected an exception similar to
> > > > this, it really should have happened on the "sturg" instruction which
> > > > does
On 4/30/20 12:48 PM, Josh Poimboeuf wrote:
On Thu, Apr 30, 2020 at 10:38:21AM -0400, Joe Lawrence wrote:
On Thu, Apr 23, 2020 at 01:10:30PM -0500, Josh Poimboeuf wrote:
This is more of note for the future, but when/if we add livepatch
support on arm64 we'll need to make the very same adjustment
nabled. Equally, a callback with the flag
> set cannot be registered if ftrace_enabled is disabled.
>
> Signed-off-by: Miroslav Benes
> ---
> v1->v2:
> - different logic, proposed by Joe Lawrence
>
> Two things I am not sure about much:
>
> - return codes. I c
.
-->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8--
>From c8c9f22e3816ca4c90ab7e7159d2ce536eaa5fad Mon Sep 17 00:00:00 2001
From: Joe Lawrence
Date: Mon, 14 Oct 2019 18:25:01 -0400
Subject: [PATCH] selftests/livepatch: test inter
-->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8--
>From a22ca55b3f429b7c9ceed6be87a571f77520994c Mon Sep 17 00:00:00 2001
From: Joe Lawrence
Date: Tue, 15 Oct 2019 10:33:18 -0400
Subject: [PATCH] selftests/livepatch: test interaction with ft
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) code for a module can be relocated
only when the relevant module is loaded.
FWIW,
On 10/15/19 11:31 AM, Jessica Yu wrote:
+++ Joe Lawrence [15/10/19 11:06 -0400]:
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
On 9/5/19 7:09 AM, Petr Mladek wrote:
On Wed 2019-09-04 21:50:55, Josh Poimboeuf wrote:
On Wed, Sep 04, 2019 at 10:49:32AM +0200, Petr Mladek wrote:
I wonder what is necessary for a productive discussion on Plumbers:
+ Josh would like to see what code can get removed when late
On 9/6/19 1:51 PM, Miroslav Benes wrote:
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
On 7/29/20 12:24 PM, Greg Kroah-Hartman wrote:
On Wed, Jul 29, 2020 at 06:13:18PM +0200, Jessica Yu wrote:
+++ Christoph Hellwig [29/07/20 08:27 +0200]:
find_symbol is only used in module.c.
Signed-off-by: Christoph Hellwig
CCing the livepatching ML, as this may or may not impact its
On 6/22/20 4:51 AM, Naresh Kamboju wrote:
On Fri, 8 May 2020 at 12:23, Michael Ellerman wrote:
It is Very Rude to clear dmesg in test scripts. That's because the
script may be part of a larger test run, and clearing dmesg
potentially destroys the output of other tests.
We can avoid using
On Wed, Jun 24, 2020 at 10:39:55AM +0200, Petr Mladek wrote:
> On Tue 2020-06-23 23:48:36, Joe Lawrence wrote:
> > On 6/22/20 4:51 AM, Naresh Kamboju wrote:
> > > On Fri, 8 May 2020 at 12:23, Michael Ellerman wrote:
> > > >
> > > > It is Very Rude to c
The livepatch samples aren't very careful with respect to compiler
IPA-optimization of target kernel functions.
Add a quick disclaimer and pointer to the compiler-considerations.rst
file to warn readers.
Suggested-by: Josh Poimboeuf
Signed-off-by: Joe Lawrence
---
samples/livepatch/README.rst
or renamed functions as part of their
build, or the selftest scripts, or even adding something to the kernel
API. I think we'll have a better idea after reviewing the compiler
considerations doc.
[1]
https://lore.kernel.org/lkml/696262e997359666afa053fe7d1a9fb2bb373964.1595010490.git.jpoim...@redhat
Compiler optimizations can have serious implications on livepatching.
Create a document that outlines common optimization patterns and safe
ways to livepatch them.
Signed-off-by: Joe Lawrence
---
.../livepatch/compiler-considerations.rst | 220 ++
Documentation/livepatch
On 7/17/20 2:29 PM, Josh Poimboeuf wrote:
Use of the new -flive-patching flag was introduced with the following
commit:
43bd3a95c98e ("kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled")
This flag has several drawbacks:
[ ... snip ... ]
- While there *is* a distro which relies
On 7/20/20 4:50 AM, Kamalesh Babulal wrote:
On 20/07/20 9:05 am, Joe Lawrence wrote:
On 7/17/20 2:29 PM, Josh Poimboeuf wrote:
Use of the new -flive-patching flag was introduced with the following
commit:
43bd3a95c98e ("kbuild: use -flive-patching when CONFIG_LIVEPATCH is
en
On 7/22/20 10:39 AM, Kees Cook wrote:
On Wed, Jul 22, 2020 at 11:27:30AM +0200, Miroslav Benes wrote:
Let me CC live-patching ML, because from a quick glance this is something
which could impact live patching code. At least it invalidates assumptions
which "sympos" is based on.
In a quick
On 7/22/20 10:51 AM, Joe Lawrence wrote:
On 7/22/20 10:39 AM, Kees Cook wrote:
On Wed, Jul 22, 2020 at 11:27:30AM +0200, Miroslav Benes wrote:
Let me CC live-patching ML, because from a quick glance this is something
which could impact live patching code. At least it invalidates assumptions
On 7/21/20 7:04 PM, Josh Poimboeuf wrote:
On Tue, Jul 21, 2020 at 12:14:06PM -0400, Joe Lawrence wrote:
Compiler optimizations can have serious implications on livepatching.
Create a document that outlines common optimization patterns and safe
ways to livepatch them.
Signed-off-by: Joe
On Tue, Jun 11, 2019 at 03:56:22PM +0200, Petr Mladek wrote:
> Hi,
>
> this is another piece in the puzzle that helps to maintain more
> livepatches.
>
> Especially pre/post (un)patch callbacks might change a system state.
> Any newly installed livepatch has to somehow deal with system state
>
On Tue, Jun 11, 2019 at 03:56:24PM +0200, 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 replaces the already installed ones. Therefore it should
nit: s/replaces/replaces
On Tue, Jun 11, 2019 at 03:56:25PM +0200, Petr Mladek wrote:
> The atomic replace runs pre/post (un)install callbacks only from the new
> livepatch. There are several reasons for this:
>
> + Simplicity: clear ordering of operations, no interactions between
> old and new callbacks.
>
>
On Tue, Jun 11, 2019 at 03:56:26PM +0200, 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 +
>
state.c
> @@ -0,0 +1,161 @@
> +// SPDX-License-Identifier: GPL-2.0
> +// Copyright (C) 2019 SUSE
>
> [ ... snip ... ]
>
> +MODULE_AUTHOR("Joe Lawrence ");
Feel free to update the module author for these.
-- Joe
On Fri, Jun 21, 2019 at 10:09:11AM -0400, Joe Lawrence wrote:
> More word play: would it be any clearer to drop the use of
> "modification" when talking about klp_states? Sometimes I read
> modification to mean a change to a klp_state itself rather than the
> system at
On 6/13/19 9:00 AM, Miroslav Benes wrote:
Hi Joe,
first, I'm sorry for the lack of response so far.
Maybe you've already noticed but the selftests fail. Well, at least in
my VM. When test_klp_convert1.ko is loaded, the process is killed with
[ 518.041826] BUG: kernel NULL pointer
On 7/26/19 12:14 PM, Steven Rostedt wrote:
On Thu, 25 Jul 2019 22:07:52 -0400
Joe Lawrence wrote:
These results reflect my underestanding of FTRACE_OPS_FL_IPMODIFY in
light of your changes, so feel free to add my:
Acked-by: Joe Lawrence
Is this an urgent patch (needs to go in now
patch: sysctl: setting key \"kernel.ftrace_enabled\": Device or resource
busy
% echo 0 > /sys/kernel/livepatch/$MOD_LIVEPATCH/enabled
livepatch: '$MOD_LIVEPATCH': initializing unpatching transition
livepatch: '$MOD_LIVEPATCH': starting unpatching transition
Looks good, thanks.
Reviewed-by: Joe Lawrence
-- Joe
ESG" - > "$LOG" || true
>
> cat "$LOG"
> # Check for expected output
I'm not familiar with running lkdtm tests, but I copied the same fixup
for the livepatching selftests and "comm" slides in nicely over there,
so,
Acked-by: Joe Lawrence
-- Joe
On Fri, Jul 10, 2020 at 05:27:35PM +0200, Petr Mladek wrote:
> On Fri 2020-07-10 10:40:43, Kamalesh Babulal wrote:
> > With procfs v3.3.16, the sysctl command doesn't prints the set key and
> > value on error. This change breaks livepatch selftest test-ftrace.sh,
> > that tests the interaction of
On 6/26/20 4:02 AM, Petr Mladek wrote:
On Wed 2020-06-24 16:12:47, Joe Lawrence wrote:
On Wed, Jun 24, 2020 at 10:39:55AM +0200, Petr Mladek wrote:
On Tue 2020-06-23 23:48:36, Joe Lawrence wrote:
On 6/22/20 4:51 AM, Naresh Kamboju wrote:
On Fri, 8 May 2020 at 12:23, Michael Ellerman wrote
On Sun, Jan 27, 2019 at 04:26:30AM +0900, Alice Ferrazzi wrote:
> This patch fixes a checkpatch warning:
> WARNING: ENOSYS means 'invalid syscall nr' and nothing else
>
> Signed-off-by: Alice Ferrazzi
> ---
> kernel/livepatch/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On Fri, Jan 11, 2019 at 08:51:54AM +0100, Nicolai Stange wrote:
> Joe Lawrence writes:
>
> > On Fri, Jan 11, 2019 at 01:00:38AM +0100, Nicolai Stange wrote:
[ ... snip ... ]
> >> For testing, could you try whether clearing the word at STACK_FRAME_MARKER
>
On Mon, Jan 14, 2019 at 08:21:40AM +0100, Nicolai Stange wrote:
> Joe Lawrence writes:
>
> > We should be careful when inspecting the bottom-most stack frame (the
> > first to be unwound), particularly for scheduled-out tasks. As Nicolai
> > Stange explains, "If I'
On 1/14/19 12:09 PM, Josh Poimboeuf wrote:
On Mon, Jan 14, 2019 at 11:46:59AM -0500, Joe Lawrence wrote:
@@ -158,11 +158,21 @@ save_stack_trace_tsk_reliable(struct task_struct *tsk,
return 1; /* invalid backlink, too far up. */
}
+ /* We can only
== sv3 && *sv3 == )
pr_info(" got expected PTR%d -> PTR%d result\n",
ptr_id(sv3), ptr_id(*sv3));
Fixes look good to me,
Acked-by: Joe Lawrence
-- Joe
was reported.
Acked-by: Joe Lawrence
-- Joe
to be emitted. The resolution
is to attach __used attribute to the shared statically declared functions.
Signed-off-by: Nicholas Mc Guire
Suggested-by: Joe Lawrence
Acked-by: Miroslav Benes
Link:
https://lore.kernel.org/lkml/1544965657-26804-1-git-send-email-hof...@osadl.org/
Hi Nicholas, thanks
ould need to be done to be confident that it is safe? Is matching on
".text.*" too inclusive?
Thanks,
-- Joe
Joe Lawrence (1):
scripts/recordmcount.{c,pl}: support -ffunction-sections .text.*
section names
scripts/recordmcount.c | 2 +-
scripts/recordmcount.pl | 13 +
mp --reloc --section __mcount_loc test_module.o
OFFSET TYPE VALUE
R_X86_64_64 .text.test_module_do_work
0008 R_X86_64_64 .text.test_module_wq_func
0010 R_X86_64_64 .init.text
Signed-off-by: Joe Lawrence
---
scripts/
- to resolve this the __noclone attribute (as
^^
nit: symbol table
> suggested by Joe Lawrence ) is used
> for the statically declared functions.
>
> Signed-off-by: Nicholas Mc Guire
> Link: https://lkml.org/lkml/2018/12/13/827
> ---
>
> sparse reported the follow
ak = kzalloc(sizeof(int), GFP_KERNEL);
> + if (!leak) {
> + kfree(d);
> + return NULL;
> + }
>
> pr_info("%s: dummy @ %p, expires @ %lx\n",
> __func__, d, d->jiffies_expire);
>
Patch v2 2/2 looks good, thanks for combining.
Acked-by: Joe Lawrence
-- Joe
On 12/14/2018 04:51 PM, Josh Poimboeuf wrote:
> On Fri, Dec 14, 2018 at 04:34:23PM -0500, Joe Lawrence wrote:
>> BTW, Petr/Miroslav/Josh, should we be annotating the selftests in
>> similar fashion?
>
> Probably so.
>
Just to clarify for Nicholas, the self-tests we'
On Sat, Dec 15, 2018 at 09:50:52AM +0100, Nicholas Mc Guire wrote:
> On Fri, Dec 14, 2018 at 04:34:23PM -0500, Joe Lawrence wrote:
> > On 12/14/2018 11:56 AM, Nicholas Mc Guire wrote:
> > > Sparse reported warnings about non-static symbols. For the variables a
> > > simp
- for those symbols referenced by
>> livepatch via klp_func the symbol-names must be unmodified in the
>> symbol table - to resolve this the __noclone attribute is used
>> for the shared statically declared functions.
>>
>> Signed-off-by: Nicholas Mc Guire
>> Suggest
On 11/20/2018 03:19 PM, Joe Lawrence wrote:
> Hi Steve,
>
> I noticed that ftrace does not currently support functions built with
> the -ffunction-sections option as they end up in .text.
> ELF sections, never making into the __mcount_loc section.
>
> I modified the
On 11/27/2018 09:09 PM, Steven Rostedt wrote:
> On Tue, 27 Nov 2018 15:27:14 -0500
> Joe Lawrence wrote:
>
>> Gentle ping... I took a dive through the rhkl-archives and found a few
>> older discussions:
>
> Thanks for the reminder, my INBOX is totally out of contr
On Wed, Nov 21, 2018 at 07:28:01PM -0500, Steven Rostedt wrote:
>
> [ ... snip ... ]
>
> Feel free to test this! I'll be pushing this to linux-next and let it
> sit there a week or so before pushing it to Linus.
>
> git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
>
On 11/28/2018 11:24 PM, Steven Rostedt wrote:
> On Wed, 28 Nov 2018 22:29:36 -0500
> Steven Rostedt wrote:
>
>> Does this patch fix it for you?
>
> Take 2. I realized that the reason for the interrupts being traced is
> because it is more likely to interrupt when the depth is already 0,
>
On 11/29/2018 11:17 AM, Steven Rostedt wrote:
> On Thu, 29 Nov 2018 10:08:55 -0500
> Joe Lawrence wrote:
>
>> With the "take 2" patch, I only see smp_irq_work_interrupt() graph when
>> the graph_function is in progress.. for example:
>
> In other words
On 12/13/2018 09:05 AM, Nicholas Mc Guire wrote:
> kzalloc() return should be checked. On dummy_alloc() failing
> in kzalloc() NULL should be returned.
>
> Signed-off-by: Nicholas Mc Guire
> ---
>
> Problem was located with an experimental coccinelle script
>
> V2: returning NULL is ok but not
On 12/13/2018 10:39 AM, Nicholas Mc Guire wrote:
> On Thu, Dec 13, 2018 at 09:14:18AM -0500, Joe Lawrence wrote:
>> On 12/13/2018 09:05 AM, Nicholas Mc Guire wrote:
>>> kzalloc() return should be checked. On dummy_alloc() failing
>>> in kzalloc() NULL should be r
On 12/13/2018 01:51 PM, Nicholas Mc Guire wrote:
> On Thu, Dec 13, 2018 at 11:39:25AM -0500, Joe Lawrence wrote:
>> On 12/13/2018 10:39 AM, Nicholas Mc Guire wrote:
>>> On Thu, Dec 13, 2018 at 09:14:18AM -0500, Joe Lawrence wrote:
>>>> On 12/13/2018 09:05 AM, Nicholas
On 12/18/2018 03:49 AM, Miroslav Benes wrote:
> On Mon, 17 Dec 2018, Joe Lawrence wrote:
>
>> I'm just being picky about its documentation and how we should note its
>> usage in the v3 patch. Think that s/__noclone/used/g of the v2 commit
>> message would be sufficient
atch does not modify the existing behavior.
>
> Suggested-by: Josh Poimboeuf
> Signed-off-by: Petr Mladek
> ---
Acked-by: Joe Lawrence
-- Joe
rd declarations.
>
> This patch does not change the code except of two forward declarations.
^
s/except of/except for
>
> Signed-off-by: Petr Mladek
> ---
Acked-by: Joe Lawrence
-- Joe
r own flag to track that the kobject was successfully
added to the hierarchy. Note that kobj.state_initialized only
indicates that kobject has been initialized, not whether is has been
added (and needs to be removed on cleanup).
>
> Signed-off-by: Petr Mladek
> Cc: Josh Poi
t; we block only modules that might still be in use after a forced
> transition. Newly loaded livepatches might be eventually completely
> removed later.
>
> It is not a big deal. But the code is at least consistent with
> the reality.
>
> Signed-off-by: Petr Mladek
Acked-by: Joe Lawrence
-- Joe
on is asynchronous already when the first
> klp_try_complete_transition() fails and another call
> is queued with a delay.
>
> Suggested-by: Josh Poimboeuf
> Signed-off-by: Petr Mladek
> ---
Acked-by: Joe Lawrence
> Documentation/livepatch/l
> [pmla...@suse.com: Initialize lists before init calls]
> Signed-off-by: Petr Mladek
> Cc: Josh Poimboeuf
> Cc: Jessica Yu
> Cc: Jiri Kosina
> Cc: Miroslav Benes
> ---
Acked-by: Joe Lawrence
-- Joe
he removal is done by a special function. It combines actions done by
> __disable_patch() and klp_complete_transition(). But it is a fast
> track without all the transaction-related stuff.
>
> Signed-off-by: Jason Baron
> [pmla...@suse.com: Split, reuse existing code, simplified
called
> asynchronously. We could not wait for them easily. Fortunately, we do
> not have to. Any further access can be avoided by removing them from
> the dynamic lists.
>
> Signed-off-by: Petr Mladek
> ---
Acked-by: Joe Lawrence
-- Joe
On Thu, Nov 29, 2018 at 10:44:29AM +0100, Petr Mladek wrote:
> User documentation for the atomic replace feature. It makes it easier
> to maintain livepatches using so-called cumulative patches.
>
> Signed-off-by: Petr Mladek
> ---
Acked-by: Joe Lawrence
> Documentation/li
^
s/handle situation/handle a situation
> (ops->func_stack) is being removed.
>
> Signed-off-by: Petr Mladek
> ---
Acked-by: Joe Lawrence
> Documentation/livepatch/cumulative-patches.txt | 11 ++
> Documentation/livepatch/livepatch.txt | 30 ---
&
On Thu, Nov 29, 2018 at 10:44:31AM +0100, Petr Mladek wrote:
> From: Joe Lawrence
>
> Add a few livepatch modules and simple target modules that the included
> regression suite can run tests against:
>
> - basic livepatching (multiple patches, atomic replace)
>
On 11/29/2018 04:44 AM, Petr Mladek wrote:
> Hi,
>
> I have an updated present for your mailboxes.
>
> The atomic replace allows to create cumulative patches. They
> are useful when you maintain many livepatches and want to remove
> one that is lower on the stack. In addition it is very useful
On 12/06/2018 03:15 AM, Petr Mladek wrote:
> On Wed 2018-12-05 14:02:20, Joe Lawrence wrote:
>> On Thu, Nov 29, 2018 at 10:44:23AM +0100, Petr Mladek wrote:
>>> The code for freeing livepatch structures is a bit scattered and tricky:
>>>
>>> [ ... snip ...
401 - 500 of 638 matches
Mail list logo
