Re: [DMARC Error] Re: [RFC PATCH] riscv: Implement HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS

Hi, On 07.03.2024 03:17, Puranjay Mohan wrote: Hi Alex, On Wed, Mar 6, 2024 at 9:35 PM Alexandre Ghiti wrote: Hi Puranjay, On 06/03/2024 17:59, Puranjay Mohan wrote: This patch enables support for DYNAMIC_FTRACE_WITH_CALL_OPS on RISC-V. This allows each ftrace callsite to provide an

Re: [PATCH] perf-probe: dso: Add symbols in .text.* subsections to text symbol map in kenrel modules

On 23.02.2021 23:11, Arnaldo Carvalho de Melo wrote: Em Tue, Feb 23, 2021 at 06:02:58PM +0300, Evgenii Shatokhin escreveu: On 23.02.2021 10:37, Masami Hiramatsu wrote: The kernel modules have .text.* subsections such as .text.unlikely. Since dso__process_kernel_symbol() only identify

Re: [PATCH] perf-probe: dso: Add symbols in .text.* subsections to text symbol map in kenrel modules

new event: probe:nf_l4proto_log_invalid (on nf_l4proto_log_invalid in nf_conntrack) You can now use it in all perf tools, such as: perf record -e probe:nf_l4proto_log_invalid -aR sleep 1 Reported-by: Evgenii Shatokhin Signed-off-by: Masami Hiramatsu Thanks for the fix!

'perf probe' and symbols from .text.

Hi, It seems, 'perf probe' can only see functions from .text section in the kernel modules, but not from .text.unlikely or other .text.* sections. For example, with kernel 5.11 and nf_conntrack.ko with debug info, 'perf probe' succeeds for nf_conntrack_attach() from .text and fails for

Re: [PATCH v4 00/10] Function Granular KASLR

Hi, On Fri, 17 Jul 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 randomization. It

Re: [PATCH v10 00/10] livepatch: Atomic replace feature

On 17.08.2018 17:53, Petr Mladek wrote: On Fri 2018-08-17 13:17:27, Evgenii Shatokhin wrote: Hi, On 07.03.2018 11:20, Petr Mladek wrote: 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

Re: [PATCH v10 00/10] livepatch: Atomic replace feature

On 17.08.2018 17:53, Petr Mladek wrote: On Fri 2018-08-17 13:17:27, Evgenii Shatokhin wrote: Hi, On 07.03.2018 11:20, Petr Mladek wrote: 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

Re: [PATCH v10 00/10] livepatch: Atomic replace feature

Hi, On 07.03.2018 11:20, Petr Mladek wrote: 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 when more patches touch the same function and there are

Re: [PATCH v10 00/10] livepatch: Atomic replace feature

Hi, On 07.03.2018 11:20, Petr Mladek wrote: 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 when more patches touch the same function and there are

Re: [PATCH v10 05/10] livepatch: Support separate list for replaced patches.

On 10.04.2018 16:21, Miroslav Benes wrote: I think you're missing my point. This isn't about your patch set, per se. It's really about our existing code. Today, our patch stack doesn't follow real stack semantics, because patches in the middle might be disabled. I see that as a problem.

Re: [PATCH v10 05/10] livepatch: Support separate list for replaced patches.

On 10.04.2018 16:21, Miroslav Benes wrote: I think you're missing my point. This isn't about your patch set, per se. It's really about our existing code. Today, our patch stack doesn't follow real stack semantics, because patches in the middle might be disabled. I see that as a problem.

Re: [PATCH v10 05/10] livepatch: Support separate list for replaced patches.

On 20.03.2018 15:25, Petr Mladek wrote: On Mon 2018-03-19 16:43:24, Josh Poimboeuf wrote: On Mon, Mar 19, 2018 at 04:02:07PM +0100, Petr Mladek wrote: Can someone remind me why we're permanently disabling replaced patches? I seem to remember being involved in that decision, but at least with

Re: [PATCH v10 05/10] livepatch: Support separate list for replaced patches.

On 20.03.2018 15:25, Petr Mladek wrote: On Mon 2018-03-19 16:43:24, Josh Poimboeuf wrote: On Mon, Mar 19, 2018 at 04:02:07PM +0100, Petr Mladek wrote: Can someone remind me why we're permanently disabling replaced patches? I seem to remember being involved in that decision, but at least with

Re: [PATCH v8 0/8] livepatch: Atomic replace feature

Hi, Petr, Jason - thanks a lot for working on this series, first of all! And especially for your patience. On 21.02.2018 16:29, Petr Mladek wrote: The atomic replace allows to create cumulative patches. They are useful when you maintain many livepatches and want to remove one that is lower

Re: [PATCH v8 0/8] livepatch: Atomic replace feature

Hi, Petr, Jason - thanks a lot for working on this series, first of all! And especially for your patience. On 21.02.2018 16:29, Petr Mladek wrote: The atomic replace allows to create cumulative patches. They are useful when you maintain many livepatches and want to remove one that is lower

Re: PATCH v6 6/6] livepatch: Add atomic replace

On 01.02.2018 00:55, Josh Poimboeuf wrote: On Fri, Jan 26, 2018 at 01:33:04PM +0300, Evgenii Shatokhin wrote: + The callbacks from the replaced patches are not called. It would be pretty hard to define a reasonable semantic and implement it. At least, it surely simplifies error

Re: PATCH v6 6/6] livepatch: Add atomic replace

On 01.02.2018 00:55, Josh Poimboeuf wrote: On Fri, Jan 26, 2018 at 01:33:04PM +0300, Evgenii Shatokhin wrote: + The callbacks from the replaced patches are not called. It would be pretty hard to define a reasonable semantic and implement it. At least, it surely simplifies error

Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On 30.01.2018 22:24, Joe Lawrence wrote: 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

Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On 30.01.2018 22:24, Joe Lawrence wrote: 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

Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On 30.01.2018 17:03, Petr Mladek wrote: On Fri 2018-01-26 14:29:36, Evgenii Shatokhin wrote: On 26.01.2018 13:23, Petr Mladek wrote: On Fri 2018-01-19 16:10:42, Jason Baron wrote: On 01/19/2018 02:20 PM, Evgenii Shatokhin wrote: On 12.01.2018 22:55, Jason Baron wrote: There is one more

Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On 30.01.2018 17:03, Petr Mladek wrote: On Fri 2018-01-26 14:29:36, Evgenii Shatokhin wrote: On 26.01.2018 13:23, Petr Mladek wrote: On Fri 2018-01-19 16:10:42, Jason Baron wrote: On 01/19/2018 02:20 PM, Evgenii Shatokhin wrote: On 12.01.2018 22:55, Jason Baron wrote: There is one more

Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On 26.01.2018 13:23, Petr Mladek wrote: On Fri 2018-01-19 16:10:42, Jason Baron wrote: On 01/19/2018 02:20 PM, Evgenii Shatokhin wrote: On 12.01.2018 22:55, Jason Baron wrote: There is one more thing that might need attention here. In my experiments with this patch series, I saw that unpatch

Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On 26.01.2018 13:23, Petr Mladek wrote: On Fri 2018-01-19 16:10:42, Jason Baron wrote: On 01/19/2018 02:20 PM, Evgenii Shatokhin wrote: On 12.01.2018 22:55, Jason Baron wrote: There is one more thing that might need attention here. In my experiments with this patch series, I saw that unpatch

Re: PATCH v6 6/6] livepatch: Add atomic replace

On 25.01.2018 19:02, Petr Mladek wrote: From: Jason Baron Sometimes we would like to revert a particular fix. Currently, this is not easy because we want to keep all other fixes active and we could revert only the last applied patch. One solution would be to apply new patch

Re: PATCH v6 6/6] livepatch: Add atomic replace

On 25.01.2018 19:02, Petr Mladek wrote: From: Jason Baron Sometimes we would like to revert a particular fix. Currently, this is not easy because we want to keep all other fixes active and we could revert only the last applied patch. One solution would be to apply new patch that implemented

Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On 12.01.2018 22:55, Jason Baron wrote: Hi, While using livepatch, I found that when doing cumulative patches, if a patched function is completed reverted by a subsequent patch (back to its original state) livepatch does not revert the funtion to its original state. Specifically, if patch A

Re: [PATCH v5 0/3] livepatch: introduce atomic replace

On 12.01.2018 22:55, Jason Baron wrote: Hi, While using livepatch, I found that when doing cumulative patches, if a patched function is completed reverted by a subsequent patch (back to its original state) livepatch does not revert the funtion to its original state. Specifically, if patch A

Re: [PATCH] hibernation: on 32-bit x86, disabled in favor of KASLR

On 23.03.2017 18:30, Rafael J. Wysocki wrote: On Thu, Mar 23, 2017 at 2:23 PM, Evgenii Shatokhin <eugene.shatok...@yandex.ru> wrote: On 23.03.2017 03:27, Kees Cook wrote: This is a modified revert of commit 65fe935dd238 ("x86/KASLR, x86/power: Remove x86 hibernation restrictio

Re: [PATCH] hibernation: on 32-bit x86, disabled in favor of KASLR

On 23.03.2017 18:30, Rafael J. Wysocki wrote: On Thu, Mar 23, 2017 at 2:23 PM, Evgenii Shatokhin wrote: On 23.03.2017 03:27, Kees Cook wrote: This is a modified revert of commit 65fe935dd238 ("x86/KASLR, x86/power: Remove x86 hibernation restrictions"), since it appears t

Re: [PATCH] hibernation: on 32-bit x86, disabled in favor of KASLR

on 32-bit since v4.8, this disables hibernation (with a warning). Booting with "nokaslr" will disable KASLR and enable hibernation. Reported-by: Evgenii Shatokhin <eugene.shatok...@yandex.ru> Signed-off-by: Kees Cook <keesc...@chromium.org> Cc: sta...@vger.kernel.org #

Re: [PATCH] hibernation: on 32-bit x86, disabled in favor of KASLR

on 32-bit since v4.8, this disables hibernation (with a warning). Booting with "nokaslr" will disable KASLR and enable hibernation. Reported-by: Evgenii Shatokhin Signed-off-by: Kees Cook Cc: sta...@vger.kernel.org # v4.8+ The patch does not work as intended on my system, unf

Re: 32-bit x86 system reboots automatically on resume from hibernate (ASLR issue?)

On 21.03.2017 23:40, Kees Cook wrote: On Tue, Mar 21, 2017 at 6:54 AM, Evgenii Shatokhin <eugene.shatok...@yandex.ru> wrote: Hi, One of my x86 machines with a 32-bit Linux system (ROSA Linux in this case) automatically reboots when it tries to resume from hibernate. This happens shortly

Re: 32-bit x86 system reboots automatically on resume from hibernate (ASLR issue?)

On 21.03.2017 23:40, Kees Cook wrote: On Tue, Mar 21, 2017 at 6:54 AM, Evgenii Shatokhin wrote: Hi, One of my x86 machines with a 32-bit Linux system (ROSA Linux in this case) automatically reboots when it tries to resume from hibernate. This happens shortly after "Image loading progres

32-bit x86 system reboots automatically on resume from hibernate (ASLR issue?)

Hi, One of my x86 machines with a 32-bit Linux system (ROSA Linux in this case) automatically reboots when it tries to resume from hibernate. This happens shortly after "Image loading progress 100%" message is shown on the screen. No traces of the error are in the system log after reboot

32-bit x86 system reboots automatically on resume from hibernate (ASLR issue?)

Hi, One of my x86 machines with a 32-bit Linux system (ROSA Linux in this case) automatically reboots when it tries to resume from hibernate. This happens shortly after "Image loading progress 100%" message is shown on the screen. No traces of the error are in the system log after reboot

[Bisected] Suspend-to-disk fails on a 32-bit x86 system since commit 92923ca

Hi, It seems, there is a regression in the kernel that prevents suspend-to-disk from working properly on some x86 machines with 32-bit Linux systems (ROSA Linux, in this case). With the mainline kernels 4.2 - 4.10, it takes more than 2 minutes from "systemctl hibernate" command till the

[Bisected] Suspend-to-disk fails on a 32-bit x86 system since commit 92923ca

Hi, It seems, there is a regression in the kernel that prevents suspend-to-disk from working properly on some x86 machines with 32-bit Linux systems (ROSA Linux, in this case). With the mainline kernels 4.2 - 4.10, it takes more than 2 minutes from "systemctl hibernate" command till the

Re: Bug with paravirt ops and livepatches

05.04.2016 16:07, Miroslav Benes пишет: On Mon, 4 Apr 2016, Josh Poimboeuf wrote: So I think this doesn't fix the problem. Dynamic relocations are applied to the "patch module", whereas the above code deals with the initialization order of the "patched module". This distinction originally

Re: Bug with paravirt ops and livepatches

05.04.2016 16:07, Miroslav Benes пишет: On Mon, 4 Apr 2016, Josh Poimboeuf wrote: So I think this doesn't fix the problem. Dynamic relocations are applied to the "patch module", whereas the above code deals with the initialization order of the "patched module". This distinction originally

Kmemleak and debug objects

Hi, When using Kmemleak on the kernel 3.10.0-229.7.2 x86_64 (RHEL 7 and the like) with CONFIG_DEBUG_OBJECTS=y, I sometimes see Kmemleak report the potential leaks of the following kind: --- unreferenced object 0x8800270e32d0 (size 40): comm "updatedb", pid 14416, jiffies

Kmemleak and debug objects

Hi, When using Kmemleak on the kernel 3.10.0-229.7.2 x86_64 (RHEL 7 and the like) with CONFIG_DEBUG_OBJECTS=y, I sometimes see Kmemleak report the potential leaks of the following kind: --- unreferenced object 0x8800270e32d0 (size 40): comm "updatedb", pid 14416, jiffies

hidepid=2 and dumpability

(Sorry, forgot to CC LKML yesterday, resending.) Hi, Could you shed some light on the implementation of 'hidepid' option for procfs in the Linux kernel? As far as I can see, has_pid_permissions() eventually calls ptrace_may_access(task, PTRACE_MODE_READ). This way, if hidepid=2 is used,

hidepid=2 and dumpability

(Sorry, forgot to CC LKML yesterday, resending.) Hi, Could you shed some light on the implementation of 'hidepid' option for procfs in the Linux kernel? As far as I can see, has_pid_permissions() eventually calls ptrace_may_access(task, PTRACE_MODE_READ). This way, if hidepid=2 is used,

[ANNOUNCE] RaceHound 1.1

RaceHound 1.1 has been released. This is a data race detector for the Linux kernel 3.14 or newer, on x86. It checks the kernel code in runtime and although it may miss some races, it produces no false alarms. It can be used to confirm the potential races found by other tools, or can be used

[ANNOUNCE] RaceHound 1.1

RaceHound 1.1 has been released. This is a data race detector for the Linux kernel 3.14 or newer, on x86. It checks the kernel code in runtime and although it may miss some races, it produces no false alarms. It can be used to confirm the potential races found by other tools, or can be used