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
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 app
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
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
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 al
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
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
th
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.
N
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 dependen
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
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 ftrac
d
Added 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 fo
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 the
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
nf_ct
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 rearr
(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, the
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 429
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 con
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
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 on
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 syst
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 tho
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
fault 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, un
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
25 matches
Mail list logo
