er. Something like this? Compile tested only for x86.
commit da8691a25d7b0c2f914720bc054dd1d9dbe4b373
Author: Stephen Brennan
Date: Fri Aug 30 10:49:24 2024 -0700
panic: make crash_kexec_post_notifiers private
This requires that any in-kernel user setting it directly must log the
reason so that users a
Masami Hiramatsu (Google) writes:
> On Thu, 2 May 2024 01:35:16 +0800
> Guo Ren wrote:
>
>> On Thu, May 2, 2024 at 12:30 AM Stephen Brennan
>> wrote:
>> >
>> > If an error happens in ftrace, ftrace_kill() will prevent disarming
>> > kprobes
Christophe Leroy writes:
> Le 01/05/2024 à 18:29, Stephen Brennan a écrit :
>> If an error happens in ftrace, ftrace_kill() will prevent disarming
>> kprobes. Eventually, the ftrace_ops associated with the kprobes will be
>> freed, yet the kprobes will still be active, and
() does not panic the
system, then we should do everything we can to continue operating,
rather than leave a ticking time bomb.
Signed-off-by: Stephen Brennan
---
Changes in v3:
Don't expose ftrace_is_dead(). Create a "kprobe_ftrace_disabled"
variable and check it directly in the
Steven Rostedt writes:
> On Mon, 29 Apr 2024 10:47:18 -0700
> Stephen Brennan wrote:
>
>> If an error happens in ftrace, ftrace_kill() will prevent disarming
>> kprobes. Eventually, the ftrace_ops associated with the kprobes will be
>> freed, yet the kprobes wil
Masami Hiramatsu (Google) writes:
> Hi Stephen,
>
> On Fri, 26 Apr 2024 15:58:34 -0700
> Stephen Brennan wrote:
>
>> If an error happens in ftrace, ftrace_kill() will prevent disarming
>> kprobes. Eventually, the ftrace_ops associated with the kprobes will be
>>
() does not panic the
system, then we should do everything we can to continue operating,
rather than leave a ticking time bomb.
Signed-off-by: Stephen Brennan
---
Difference from v1: removed both existing declarations of ftrace_is_dead()
from kernel/trace/trace.h.
arch/csky/kernel/probes/ftrace.c
() does not panic the
system, then we should do everything we can to continue operating,
rather than leave a ticking time bomb.
Signed-off-by: Stephen Brennan
---
Apologies for the wide net cast here. I recognize that a change like this
may need to be split up and go through arch-specific trees. I
Mike Rapoport writes:
> From: Mike Rapoport
>
> There are no architectures that support DISCONTIGMEM left.
>
> Remove the configuration option and the dead code it was guarding in the
> generic memory management code.
>
> Signed-off-by: Mike Rapoport
> ---
> include/asm-generic/memory_model.h |
