Hi,
On Mon, 30 Sep 2024, Michael Vetter wrote:
> The test proves that a function that is being kprobed and uses a
> post_handler cannot be livepatched.
>
> Only one ftrace_ops with FTRACE_OPS_FL_IPMODIFY set may be registered
> to any given function at a time.
>
> Signed-off-by: Michael Vetter
Hi,
On Mon, 30 Sep 2024, Michael Vetter wrote:
> This naming makes more sense according to the directory structure.
> Especially when we later add more paths.
>
> Signed-off-by: Michael Vetter
> ---
> tools/testing/selftests/livepatch/functions.sh | 6 +++---
> 1 file changed, 3 insertions(+),
Hello,
On Sun, 29 Sep 2024, Wardenjohn wrote:
> As previous discussion, maintainers think that patch-level sysfs interface is
> the
> only acceptable way to maintain the information of the order that klp_patch
> is
> applied to the system.
>
> However, the previous patch introduce klp_ops int
On Wed, 25 Sep 2024, Wardenjohn wrote:
> Update description of klp_patch stack_order sysfs interface to
> livepatch ABI documentation.
>
> Signed-off-by: Wardenjohn
>
> diff --git a/Documentation/ABI/testing/sysfs-kernel-livepatch
> b/Documentation/ABI/testing/sysfs-kernel-livepatch
> index a5
hat livepatch_1 is the first live patch applied
cat /sys/kernel/livepatch/livepatch_module/stack_order -> N
means that livepatch_module is the Nth live patch applied
"
?
> Suggested-by: Petr Mladek
> Suggested-by: Miroslav Benes
> Suggested-by: Josh Poimboeuf
> Signed
Hi,
On Fri, 20 Sep 2024, Michael Vetter wrote:
> +# Kprobe a function and verify that we can't livepatch that same function
> +# when it uses a post_handler since only one IPMODIFY maybe be registered
> +# to any given function at a time.
> +
> +start_test "livepatch interaction with kprobed func
Hi,
On Fri, 20 Sep 2024, Michael Vetter wrote:
> Save the state of /sys/kernel/livepatch/debug/kprobes/enabled
I believe it is /sys/kernel/debug/kprobes/enabled.
> during setup_config() and restore it during cleanup().
>
> This is in preparation for a future commit that will add a test
> that
Hi,
On Thu, 5 Sep 2024, zhang warden wrote:
>
> Hi, Miroslav
> > On Sep 5, 2024, at 18:10, Miroslav Benes wrote:
> >
> > Hi,
> >
> > the subject is missing "livepatch: " prefix and I would prefer something
> > like
> >
> > &qu
On Thu, 5 Sep 2024, Josh Poimboeuf wrote:
> On Thu, Sep 05, 2024 at 12:23:20PM +0200, Miroslav Benes wrote:
> > I am not a fan. Josh wrote most of my objections already so I will not
> > repeat them. I understand that the attribute might be useful but the
> > amount of code
Hi,
On Wed, 28 Aug 2024, Wardenjohn wrote:
> One system may contains more than one livepatch module. We can see
> which patch is enabled. If some patches applied to one system
> modifing the same function, livepatch will use the function enabled
> on top of the function stack. However, we can not
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
| 4 ---
> 4 files changed, 9 insertions(+), 103 deletions(-)
I was on holiday most of August and the patch set has been merged but let
me at least add
Acked-by: Miroslav Benes
here since I participated in the discussion at the beginning.
Thank you for cleaning it up!
Miroslav
Hi,
On Thu, 15 Aug 2024, Sami Tolvanen wrote:
> Distributions that want to maintain a stable kABI need the ability to
> add reserved fields to kernel data structures that they anticipate
> will be modified during the ABI support timeframe, either by LTS
> updates or backports.
>
> With genksyms,
Hi Petr,
On Fri, 10 Nov 2023, Petr Mladek wrote:
> This POC is a material for the discussion "Simplify Livepatch Callbacks,
> Shadow Variables, and States handling" at LPC 2013, see
> https://lpc.events/event/17/contributions/1541/
>
> It obsoletes the patchset adding the garbage collection of s
On Fri, 10 Nov 2023, Josh Poimboeuf wrote:
> On Fri, Nov 10, 2023 at 06:04:21PM +0100, Petr Mladek wrote:
> > This POC is a material for the discussion "Simplify Livepatch Callbacks,
> > Shadow Variables, and States handling" at LPC 2013, see
> > https://lpc.events/event/17/contributions/1541/
> >
On Fri, 10 Nov 2023, Petr Mladek wrote:
> The livepatch state API was added to help with maintaining:
>
>+ changes done by livepatch callbasks
>+ lifetime of shadow variables
>
> The original API was hard to use. Both objectives are better handled
> by the new per-state callbacks. They a
> diff --git a/lib/livepatch/test_klp_speaker.c
> b/lib/livepatch/test_klp_speaker.c
> index d2d31072639a..d8e42267f5cd 100644
> --- a/lib/livepatch/test_klp_speaker.c
> +++ b/lib/livepatch/test_klp_speaker.c
> @@ -9,23 +9,174 @@
>
> #include
> #include
> +#include
> +#include
> +
> +#incl
Hi,
On Fri, 10 Nov 2023, Petr Mladek wrote:
> Recent changes in the livepatch core have allowed to connect states,
> shadow variables, and callbacks. Use these new features in
> the state tests.
>
> Use the shadow variable API to store the original loglevel. It is
> better suited for this purpos
> diff --git a/kernel/livepatch/state.c b/kernel/livepatch/state.c
> index 6693d808106b..4ec65afe3a43 100644
> --- a/kernel/livepatch/state.c
> +++ b/kernel/livepatch/state.c
> @@ -198,11 +198,17 @@ void klp_release_states(struct klp_patch *patch)
> if (is_state_in_other_patches(patch
Hi,
On Thu, 18 Jul 2024, zhangyongde.zyd wrote:
> From: Wardenjohn
>
> One system may contains more than one livepatch module. We can see
> which patch is enabled. If some patches applied to one system
> modifing the same function, livepatch will use the function enabled
> on top of the functio
On Fri, 7 Jun 2024, Song Liu wrote:
> Hi Miroslav,
>
> Thanks for reviewing the patch!
>
> On Fri, Jun 7, 2024 at 6:06 AM Miroslav Benes wrote:
> >
> > Hi,
> >
> > On Tue, 4 Jun 2024, Song Liu wrote:
> >
> > > With CONFIG_LTO_CLANG, the c
Hi,
On Thu, 20 Jun 2024, zhang warden wrote:
>
>
> > On Jun 7, 2024, at 17:07, Miroslav Benes wrote:
> >
> > It would be better than this patch but given what was mentioned in the
> > thread I wonder if it is possible to use ftrace even for this. See
>
Hi,
On Tue, 4 Jun 2024, Song Liu wrote:
> With CONFIG_LTO_CLANG, the compiler may postfix symbols with .llvm.
> to avoid symbol duplication. scripts/kallsyms.c sorted the symbols
> without these postfixes. The default symbol lookup also removes these
> postfixes before comparing symbols.
>
> On
Hi,
On Tue, 4 Jun 2024, Song Liu wrote:
> On Tue, May 21, 2024 at 1:04 AM Petr Mladek wrote:
> [...]
> > >
> > > Yes, but the information you get is limited compared to what is available
> > > now. You would obtain the information that a patched function was called
> > > but ftrace could also gi
Hi,
On Fri, 31 May 2024, Joe Lawrence wrote:
> On 5/31/24 07:23, Miroslav Benes wrote:
> > Hi,
> >
> > On Tue, 21 Jul 2020, Joe Lawrence wrote:
> >
> >> In light of [PATCH] Revert "kbuild: use -flive-patching when
> >> CONFIG_LIVEPATCH is
> And for the unlikely branch, isn’t the complier will compile this branch
> into a cold branch that will do no harm to the function performance?
The test (cmp insn or something like that) still needs to be there. Since
there is only a simple assignment in the branch, the compiler may just
choo
Hi,
On Tue, 21 Jul 2020, Joe Lawrence wrote:
> In light of [PATCH] Revert "kbuild: use -flive-patching when
> CONFIG_LIVEPATCH is enabled" [1], we should add some loud disclaimers
> and explanation of the impact compiler optimizations have on
> livepatching.
>
> The first commit provides detaile
Hi,
On Fri, 31 May 2024, zhang warden wrote:
>
> Hi Bros,
>
> How about my patch? I do think it is a viable feature to show the state
> of the patched function. If we add an unlikely branch test before we set
> the 'called' state, once this function is called, there maybe no
> negative effec
Hello,
On Mon, 20 May 2024, zhang warden wrote:
>
>
> > On May 20, 2024, at 14:46, Miroslav Benes wrote:
> >
> > Hi,
> >
> > On Mon, 20 May 2024, Wardenjohn wrote:
> >
> >> Livepatch module usually used to modify kernel functions.
> >
Hi,
On Mon, 20 May 2024, Wardenjohn wrote:
> Livepatch module usually used to modify kernel functions.
> If the patched function have bug, it may cause serious result
> such as kernel crash.
>
> This is a kobject attribute of klp_func. Sysfs interface named
> "called" is introduced to livepatch
On Tue, 7 May 2024, zhangwar...@gmail.com wrote:
> From: Wardenjohn
>
> The original macros of KLP_* is about the state of the transition.
> Rename macros of KLP_* to KLP_TRANSITION_* to fix the confusing
> description of klp transition state.
>
> Signed-off-by: Wardenjohn
Hi,
> > Summary of changes in this minimal version
> >
> >
> > - rebase for v6.5
> > - cleaned-up SoB chains (suggested by pmladek)
> > - klp-convert: remove the symbol map auto-resolving solution
> > - klp-convert: add macro for flagging variables inside a LP src to be
Hello,
On Fri, 11 Aug 2023, Miroslav Benes wrote:
> Hi,
>
> On Wed, 14 Jun 2023, Miroslav Benes wrote:
>
> > Hello,
> >
> > the Live Patching Microconference for Linux Plumbers Conference 2023 has
> > been accepted.
> >
> > It is possible
On Wed, 14 Apr 2021, Josef Bacik wrote:
> On 4/14/21 11:21 AM, xiaojun.zhao...@gmail.com wrote:
> > On Wed, 14 Apr 2021 13:27:43 +0200 (CEST)
> > Miroslav Benes wrote:
> >
> >> Hi,
> >>
> >> On Wed, 14 Apr 2021, xiaojun.zhao...@gmail.com wrote:
Hi,
On Wed, 14 Apr 2021, xiaojun.zhao...@gmail.com wrote:
> I found the qemu-nbd process(started with qemu-nbd -t -c /dev/nbd0
> nbd.qcow2) will automatically exit when I patched for functions of
> the nbd with livepatch.
>
> The nbd relative source:
> static int nbd_start_device_ioctl(struct nb
Hi,
> > Driver developers will simply have to open code these protections. In
> > light of what I see on LTP / fuzzing, I suspect the use case will grow
> > and we'll have to revisit this in the future. But for now, sure, we can
> > just open code the required protections everywhere to not crash o
have been completely
> rewritten, but it all seems to work nicely.
Reviewed-by: Miroslav Benes
for the objtool changes. All looks much better in this version.
I have only one minor thing. There are only two call sites of
elf_add_string(). The one in elf_create_section() passes shstrtab, th
ur bespoke solution with the generic one.
Reviewed-by: Jens Axboe
Reviewed-by: Petr Mladek
Signed-off-by: Miroslav Benes
---
v2:
- #include from kernel/signal.c removed [Petr]
kernel/livepatch/transition.c | 5 ++---
kernel/signal.c | 4 +---
2 files changed, 3 insertions(+), 6
ur bespoke solution with the generic one.
Signed-off-by: Miroslav Benes
---
Tested on x86_64, s390x and ppc64le archs.
kernel/livepatch/transition.c | 5 ++---
kernel/signal.c | 3 +--
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/kernel/livepatch/transition.
On Thu, 25 Mar 2021, Jens Axboe wrote:
> On 3/25/21 3:30 AM, Miroslav Benes wrote:
> >> (PF_KTHREAD | PF_IO_WORKER) is open coded in soo many places maybe this is
> >> a
> >> silly question, but...
> >>
> >> If the livepatch code could use fake
> (PF_KTHREAD | PF_IO_WORKER) is open coded in soo many places maybe this is a
> silly question, but...
>
> If the livepatch code could use fake_signal_wake_up(), we could consolidate
> the pattern in klp_send_signals() with the one in freeze_task(). Then there
> would only one place for wake up
On Thu, 25 Mar 2021, Dong Kai wrote:
> commit 15b2219facad ("kernel: freezer should treat PF_IO_WORKER like
> PF_KTHREAD for freezing") is to fix the freezeing issue of IO threads
> by making the freezer not send them fake signals.
>
> Here live patching consistency model call klp_send_signals to
On Thu, 25 Mar 2021, Bhaskar Chowdhury wrote:
> On 10:05 Thu 25 Mar 2021, Miroslav Benes wrote:
> >Hi,
> >
> >On Thu, 25 Mar 2021, Bhaskar Chowdhury wrote:
> >
> >>
> >> s/varibles/variables/
> >>
> >> Signed-off-by: Bhaskar Chowdh
Hi,
On Thu, 25 Mar 2021, Bhaskar Chowdhury wrote:
>
> s/varibles/variables/
>
> Signed-off-by: Bhaskar Chowdhury
> ---
> Documentation/livepatch/shadow-vars.rst | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/livepatch/shadow-vars.rst
> b/Documentation
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -1045,6 +1045,12 @@ static int add_call_destinations(struct
> } else
> insn->call_dest = reloc->sym;
>
> + if (insn->call_dest && insn->call_dest->static_call_tramp) {
> +
On Wed, 17 Mar 2021, Peter Zijlstra wrote:
> On Wed, Mar 17, 2021 at 02:52:23PM +0100, Miroslav Benes wrote:
>
> > > + if (!elf_symbol_add(elf, sym, SHN_XINDEX)) {
> > > + WARN("elf_symbol_add");
> > > + return NULL;
> > > + }
[ also correcting my e-mail address ]
On Fri, 12 Mar 2021, Peter Zijlstra wrote:
Just a remark regarding SHN_XINDEX...
> +static bool elf_symbol_add(struct elf *elf, struct symbol *sym, Elf32_Word
> shndx)
> +{
> + struct list_head *entry;
> + struct rb_node *pnode;
> +
> + sym->typ
Hi Masami,
> --- a/include/linux/kprobes.h
> +++ b/include/linux/kprobes.h
> @@ -205,15 +205,23 @@ extern void arch_prepare_kretprobe(struct
> kretprobe_instance *ri,
> struct pt_regs *regs);
> extern int arch_trampoline_kprobe(struct kprobe *p);
>
> +void kret
Hi,
I cannot really comment on mips arch specifics but few words from the live
patching perspective.
On Mon, 1 Mar 2021, Jinyang He wrote:
> Add the basic code of livepatch. livepatch is temporarily unavailable.
> Two core functions are missing, one is DYNAMIC_FTRACE_WITH_REGS, and
> another is
sed by missing ORC data
>
> arch/x86/kernel/unwind_orc.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
I apologize for a really late reply. It seems it has not been merged yet,
so
Reviewed-by: Miroslav Benes
M
>
> Fixes: 013c1667cf78 ("kallsyms: refactor {,module_}kallsyms_on_each_symbol")
> Signed-off-by: Dan Carpenter
Reviewed-by: Miroslav Benes
M
gt;
> - rebased to tip/objtool/core
I haven't tested it, but it all looks good to me.
Reviewed-by: Miroslav Benes
M
On Tue, 9 Feb 2021, Steven Rostedt wrote:
> On Tue, 9 Feb 2021 09:32:34 +0100 (CET)
> Miroslav Benes wrote:
>
> > powerpc has this
> >
> > static inline unsigned long klp_get_ftrace_l
On Mon, 8 Feb 2021, Steven Rostedt wrote:
> On Mon, 8 Feb 2021 16:47:05 +0100
> Peter Zijlstra wrote:
>
> > > /*
> > > * Convert a function address into the appropriate ftrace location.
> > > *
> > > * Usually this is just the address of the function, but on some
> > > architectures
> > > *
mbol_args to find_symbol
>
> Simplify the calling convention by passing the find_symbol_args structure
> to find_symbol instead of initializing it inside the function.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Miroslav Benes
M
On Tue, 2 Feb 2021, Christoph Hellwig wrote:
> each_symbol_in_section just contains a trivial loop over its arguments.
> Just open code the loop in the two callers.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Miroslav Benes
M
On Tue, 2 Feb 2021, Christoph Hellwig wrote:
> each_symbol_section is only called by find_symbol, so merge the two
> functions.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Miroslav Benes
M
> void *__symbol_get(const char *symbol)
> {
> - struct module *owner;
> - const struct kernel_symbol *sym;
> + struct find_symbol_arg fsa = {
> + .name = symbol,
> + .gplok = true,
> + .warn = true,
> + };
>
> preempt_disable();
>
On Tue, 2 Feb 2021, Christoph Hellwig wrote:
> EXPORT_UNUSED_SYMBOL* is not actually used anywhere. Remove the
> unused functionality as we generally just remove unused code anyway.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Miroslav Benes
M
On Tue, 2 Feb 2021, Christoph Hellwig wrote:
> As far as I can tell this has never been used at all, and certainly
> not any time recently.
Right, I've always wondered about this one.
> Signed-off-by: Christoph Hellwig
Reviewed-by: Miroslav Benes
M
On Tue, 2 Feb 2021, Christoph Hellwig wrote:
> struct symsearch is only used inside of module.h, so move the definition
> out of module.h.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Miroslav Benes
M
-off-by: Christoph Hellwig
Reviewed-by: Miroslav Benes
M
On Tue, 2 Feb 2021, Christoph Hellwig wrote:
> kallsyms_on_each_symbol and module_kallsyms_on_each_symbol are only used
> by the livepatching code, so don't build them if livepatching is not
> enabled.
>
> Signed-off-by: Christoph Hellwig
Reviewed-by: Miroslav Benes
M
On Mon, 1 Feb 2021, Christoph Hellwig wrote:
> On Mon, Feb 01, 2021 at 02:37:12PM +0100, Miroslav Benes wrote:
> > > > This change is not needed. (objname == NULL) means that we are
> > > > interested only in symbols in "vmlinux".
> > > >
> &g
One more thing...
> @@ -4379,8 +4379,7 @@ int module_kallsyms_on_each_symbol(int (*fn)(void *,
> const char *,
> unsigned int i;
> int ret;
>
> - module_assert_mutex();
> -
> + mutex_lock(&module_mutex);
> list_for_each_entry(mod, &modules, list) {
> /* W
On Mon, 1 Feb 2021, Christoph Hellwig wrote:
> On Fri, Jan 29, 2021 at 10:43:36AM +0100, Petr Mladek wrote:
> > > --- a/kernel/livepatch/core.c
> > > +++ b/kernel/livepatch/core.c
> > > @@ -164,12 +164,8 @@ static int klp_find_object_symbol(const char
> > > *objname, const char *name,
> > >
On Mon, 1 Feb 2021, Jessica Yu wrote:
> +++ Miroslav Benes [29/01/21 16:29 +0100]:
> >On Thu, 28 Jan 2021, Christoph Hellwig wrote:
> >
> >> Allow for a RCU-sched critical section around find_module, following
> >> the lower level find_module_all helper, and switc
: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: "H. Peter Anvin"
> Cc: Heiko Carstens
> Cc: Vasily Gorbik
> Cc: Christian Borntraeger
> Cc: Josh Poimboeuf
> Cc: Jiri Kosina
> Cc: Miroslav Benes
> Cc: Petr Mladek
> Cc: Joe Lawrence
stacktrace.rst | 309 ++
> 4 files changed, 313 insertions(+), 22 deletions(-)
> create mode 100644 Documentation/livepatch/reliable-stacktrace.rst
sorry for the late reply (slowly crawling through my email backlog).
Thanks a lot for putting this together!
FWIW (so it is at least archived in the thread)
Acked-by: Miroslav Benes
M
le (and bots) looking for objtool warnings than
> ever before, so such warnings not likely to be ignored for long.
>
> Suggested-by: Nick Desaulniers
> Signed-off-by: Josh Poimboeuf
Reviewed-by: Miroslav Benes
M
lor
> Signed-off-by: Josh Poimboeuf
Reviewed-by: Miroslav Benes
with the note below.
> ---
> tools/objtool/elf.c | 7 +--
> 1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/tools/objtool/elf.c b/tools/objtool/elf.c
> index be89c741ba9a..2b0f
> That comment is indeed now obsolete. I can squash something like so:
>
> diff --git a/tools/objtool/check.c b/tools/objtool/check.c
> index 81d56fdef1c3..ce67437aaf3f 100644
> --- a/tools/objtool/check.c
> +++ b/tools/objtool/check.c
> @@ -958,21 +958,8 @@ static int add_call_destinations(struc
On Tue, 22 Dec 2020, Josh Poimboeuf wrote:
> BTW, another benefit of these changes is that, thanks to some related
> cleanups (new fake nops and alt_group struct) objtool can finally be rid
> of fake jumps, which were a constant source of headaches.
\o/
You may also want to remove/edit the comme
Reviewed-by: Nick Desaulniers
> Link: https://github.com/ClangBuiltLinux/linux/issues/1207
> Signed-off-by: Josh Poimboeuf
Reviewed-by: Miroslav Benes
M
> diff --git a/arch/x86/include/asm/ftrace.h b/arch/x86/include/asm/ftrace.h
> index e00fe88146e0..7c9474d52060 100644
> --- a/arch/x86/include/asm/ftrace.h
> +++ b/arch/x86/include/asm/ftrace.h
> @@ -54,6 +54,9 @@ arch_ftrace_get_regs(struct ftrace_regs *fregs)
> return NULL;
>
npatched function will be called
> placing the system into an unknown state.
>
> Link: https://lore.kernel.org/r/20201029145709.GD16774@alley
>
> Cc: Josh Poimboeuf
> Cc: Jiri Kosina
> Cc: Joe Lawrence
> Cc: live-patch...@vger.kernel.org
> Suggested-by: Miroslav Benes
28115613.291169...@goodmis.org
>
> Cc: Masami Hiramatsu
> Cc: Andrew Morton
> Cc: Josh Poimboeuf
> Cc: Jiri Kosina
> Cc: Miroslav Benes
> Cc: Joe Lawrence
> Cc: live-patch...@vger.kernel.org
> Reviewed-by: Petr Mladek
> Signed-off-by: Steven Rostedt (VMware)
Acked-by: Miroslav Benes
M
_sig_check()
> [2/3] module: avoid *goto*s in module_sig_check()
> [3/3] module: only handle errors with the *switch* statement in
> module_sig_check()
Reviewed-by: Miroslav Benes
M
passed my tests too and the patch looks good to me, so
Acked-by: Miroslav Benes
M
> Signed-off-by: Steven Rostedt (VMware)
> ---
> arch/powerpc/include/asm/livepatch.h | 4 +++-
> arch/s390/include/asm/livepatch.h| 5 -
> arch/x86/include/asm/ftrace.h| 3 +++
> a
> > > > + bit = ftrace_test_recursion_trylock();
> > > > + if (bit < 0)
> > > > + return;
> > >
> > > This means that the original function will be called in case of
> > > recursion.
> > > That's probably fair, but I'm wondering if we should at least WARN about
> > >
Hi,
> +static __always_inline int trace_get_context_bit(void)
> +{
> + int bit;
> +
> + if (in_interrupt()) {
> + if (in_nmi())
> + bit = 0;
> +
> + else if (in_irq())
> + bit = 1;
> + else
> +
On Thu, 29 Oct 2020, Petr Mladek wrote:
> On Thu 2020-10-29 14:51:06, Miroslav Benes wrote:
> > On Wed, 28 Oct 2020, Steven Rostedt wrote:
>
> > Hm, I've always thought that we did not need any kind of recursion
> > protection for our callback. It is marked as
and the patch set
correctly.
> Cc: Josh Poimboeuf
> Cc: Jiri Kosina
> Cc: Miroslav Benes
> Cc: Petr Mladek
> Cc: Joe Lawrence
> Cc: live-patch...@vger.kernel.org
> Signed-off-by: Steven Rostedt (VMware)
> ---
> kernel/livepatch/patch.c | 5 +
> 1 file chan
On Wed, 28 Oct 2020, Jessica Yu wrote:
> +++ Miroslav Benes [27/10/20 15:03 +0100]:
> >If a module fails to load due to an error in prepare_coming_module(),
> >the following error handling in load_module() runs with
> >MODULE_STATE_COMING in module's state. F
Hi,
On Fri, 23 Oct 2020, Mark Rutland wrote:
> Add documentation for reliable stacktrace. This is intended to describe
> the semantics and to be an aid for implementing architecture support for
> HAVE_RELIABLE_STACKTRACE.
thanks a lot for doing the work!
> Unwinding is a subtle area, and archit
If a module fails to load due to an error in prepare_coming_module(),
the following error handling in load_module() runs with
MODULE_STATE_COMING in module's state. Fix it by correctly setting
MODULE_STATE_GOING under "bug_cleanup" label.
Signed-off-by: Miroslav Benes
---
kern
On Sat, 10 Oct 2020, Jens Axboe wrote:
> On 10/9/20 9:21 AM, Jens Axboe wrote:
> > On 10/9/20 2:01 AM, Miroslav Benes wrote:
> >> On Thu, 8 Oct 2020, Oleg Nesterov wrote:
> >>
> >>> On 10/05, Jens Axboe wrote:
> >>>>
> >>>> Hi,
On Thu, 8 Oct 2020, Oleg Nesterov wrote:
> On 10/05, Jens Axboe wrote:
> >
> > Hi,
> >
> > The goal is this patch series is to decouple TWA_SIGNAL based task_work
> > from real signals and signal delivery.
>
> I think TIF_NOTIFY_SIGNAL can have more users. Say, we can move
> try_to_freeze() from
On Fri, 2 Oct 2020, Josh Poimboeuf wrote:
> On Thu, Oct 01, 2020 at 03:36:12PM +0200, Peter Zijlstra wrote:
> > On Thu, Oct 01, 2020 at 03:17:07PM +0200, Miroslav Benes wrote:
> >
> > > I also wonder about making 'mcount' command separate from 'check'
Hi Sami,
On Tue, 29 Sep 2020, Sami Tolvanen wrote:
> From: Peter Zijlstra
>
> Add the --mcount option for generating __mcount_loc sections
> needed for dynamic ftrace. Using this pass requires the kernel to
> be compiled with -mfentry and CC_USING_NOP_MCOUNT to be defined
> in Makefile.
>
> Li
Hi Kristen,
On Wed, 23 Sep 2020, Kristen Carlson Accardi wrote:
> Function Granular Kernel Address Space Layout Randomization (fgkaslr)
> -
>
> This patch set is an implementation of finer grained kernel address space
> randomiz
Hi,
On Wed, 23 Sep 2020, Kristen Carlson Accardi wrote:
> If any type of function granular randomization is enabled, the sympos
> algorithm will fail, as it will be impossible to resolve symbols when
> there are duplicates using the previous symbol position.
>
> Override the value of sympos to a
arm64: stacktrace: Make stack walk callback consistent with generic
> code
> arm64: stacktrace: Convert to ARCH_STACKWALK
The patches look good to me.
Reviewed-by: Miroslav Benes
M
[4] https://lkml.org/lkml/2020/7/30/424
Hi,
Josh merged the patch set already, but FWIW
Reviewed-by: Miroslav Benes
for the new changes (patches 7, 9 and 10).
Miroslav
On Thu, 3 Sep 2020, Josh Poimboeuf wrote:
> On Wed, Aug 12, 2020 at 10:57:11AM -0700, Kristen Carlson Accardi wrote:
>
> > if (GELF_ST_TYPE(sym.st_info) == STT_SECTION) {
> > - scn = elf_getscn(elf, sym.st_shndx);
> > + if ((
On Wed, 12 Aug 2020, Kristen Carlson Accardi wrote:
> When getting the symbol index number, make sure to use the
> extended symbol table information in order to support symbol
> index's greater than 64K.
>
> Signed-off-by: Kristen Carlson Accardi
Reviewed-by: Miroslav Benes
M
Hi,
first, I'm sorry for the late reply. Thanks, Josh, for the reminder.
CCing Nicolai. Nicolai, could you take a look at the proposed
documentation too, please? You have more up-to-date experience.
On Tue, 21 Jul 2020, Joe Lawrence wrote:
> +Examples
> +
> +
> +Interprocedural optimiz
[side note: So not only that my INBOX is a mess after the summer. I also
lost some emails apparently. I'm really sorry about that. ]
CCing Nicolai too.
> Hi Petr, Josh,
>
> The compiler optimization pitfall document can wait for refactored livepatch
> documentation if that puts it into better c
ggested-by: Josh Poimboeuf
> Signed-off-by: Joe Lawrence
Acked-by: Miroslav Benes
M
Hi,
it could be a silly question, but better to ask...
> + if (regs)
> + start_backtrace(&frame, regs->regs[29], regs->pc);
> + else
> + start_backtrace(&frame, thread_saved_fp(task),
> + thread_saved_pc(task));
Would this also work for
1 - 100 of 799 matches
Mail list logo
