On Tue, 13 May 2025, Peter Zijlstra wrote:
> On Tue, May 13, 2025 at 03:34:50PM +0200, Miroslav Benes wrote:
> > Hi,
> >
> > thanks for the updated version.
> >
> > On Fri, 9 May 2025, Sebastian Andrzej Siewior wrote:
> >
> > > From: Peter Zij
mments]
>
> Signed-off-by: Peter Zijlstra (Intel)
> Signed-off-by: Sebastian Andrzej Siewior
Acked-by: Miroslav Benes
A nit below if there is an another version, otherwise Petr might fix it
when merging.
> @@ -365,27 +356,20 @@ static bool klp_try_switch_task(struct task_struct
>
> void __klp_sched_try_switch(void)
> {
> - if (likely(!klp_patch_pending(current)))
> - return;
> -
> /*
>* This function is called from cond_resched() which is called in many
>* places throughout the kernel. Using the klp_mutex here might
> @@ -377,14 +365
On Wed, 26 Mar 2025, Peter Zijlstra wrote:
> On Wed, Mar 26, 2025 at 03:37:50PM +0100, Miroslav Benes wrote:
>
> > If I remember correctly, we had something like this in the old kGraft
> > implementation of the live patching (SUSE way). We exactly had a hook
> >
Hi,
On Wed, 26 Mar 2025, Peter Zijlstra wrote:
> On Wed, Mar 26, 2025 at 10:49:10AM +0100, Petr Mladek wrote:
> > On Mon 2025-03-24 14:49:09, Peter Zijlstra wrote:
> > >
> > > With the goal of deprecating / removing VOLUNTARY preempt, live-patch
> > > needs to stop relying on cond_resched() to m
detect when the stack
> trace is not reliable, which is enough to provide reliable livepatching.
>
> Signed-off-by: Song Liu
Looks good to me.
Reviewed-by: Miroslav Benes
M
d-by: Marcos Paulo de Souza
Acked-by: Miroslav Benes
M
On Fri, 14 Mar 2025, Filipe Xavier wrote:
> On 3/14/25 10:14 AM, Miroslav Benes wrote:
>
> > Hi,
> >
> >> +start_test "trace livepatched function and check that the live patch
> >> remains in effect"
> >> +
> >> +FUNCTION_NAME=&
Hi,
> +start_test "trace livepatched function and check that the live patch remains
> in effect"
> +
> +FUNCTION_NAME="livepatch_cmdline_proc_show"
> +
> +load_lp $MOD_LIVEPATCH
> +trace_function "$FUNCTION_NAME"
trace_funtion() calls cleanup_ftrace() to prepare the test. Ok.
> +if [[ "$(cat /p
a...@amazon.com/
> [2] https://github.com/liu-song-6/kpatch/tree/fb-6.13
> Cc: Suraj Jitindar Singh
> Cc: Torsten Duwe
> Signed-off-by: Song Liu
Acked-by: Miroslav Benes
Also as mentioned in the other thread, parts of this patch will go once
arm64 is converted to generic entry infrastructure.
Thank you,
Miroslav
Hi,
> diff --git a/arch/arm64/kernel/entry-common.c
> b/arch/arm64/kernel/entry-common.c
> index b260ddc4d3e9..b537af333b42 100644
> --- a/arch/arm64/kernel/entry-common.c
> +++ b/arch/arm64/kernel/entry-common.c
> @@ -8,6 +8,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> >
> > + What exactly is meant by frequent replacements (busy loop?, once a
> > minute?)
>
> The script:
>
> #!/bin/bash
> while true; do
> yum install -y ./kernel-livepatch-6.1.12-0.x86_64.rpm
> ./apply_livepatch_61.sh # it will sleep 5s
> yum erase -y kernel-livepatc
Hi,
On Thu, 21 Nov 2024, George Guo wrote:
> From: George Guo
>
> The script test-callbacks.sh fails with the following error:
> $ sudo ./test-callbacks.sh
> TEST: target module before livepatch ... not ok
>
> - expected
> + result
> test_klp_callbacks_mod: test_klp_callbacks_mod_init
> % in
robe_ftrace().
>
> Signed-off-by: Michael Vetter
Nice test.
Reviewed-by: Miroslav Benes
Thank you,
Miroslav
there are still two occurrences of /sys/kernel/ in test-syscall.sh which
can be replaced with $SYSFS_KERNEL_DIR now. I suppose that Petr can fix
that when applying as well.
The patch also contains two separate things... the cleanup and the kprobe
state handling. Ideally, it should be split but unless someone else also
speaks up, I can certainly live with the current state.
With that
Reviewed-by: Miroslav Benes
M
epatch_1/stack_order -> 1
>
> means that 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: Miros
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
1 - 100 of 815 matches
Mail list logo
