Displaying 7 results from an estimated 7 matches for "ftrace_op".
Did you mean:
ftrace_ops
2017 Oct 04
1
[RFC v3 20/27] x86/ftrace: Adapt function tracing for PIE support
...f call *got */
+
+/*
+ * MCOUNT_INSN_SIZE is the highest size of instructions based on the
+ * configuration.
+ */
+#ifdef CONFIG_X86_PIE
+#define MCOUNT_INSN_SIZE MCOUNT_GOTCALL_SIZE
+#else
+#define MCOUNT_INSN_SIZE MCOUNT_RELINSN_SIZE
+#endif
#ifdef CONFIG_DYNAMIC_FTRACE
#define ARCH_SUPPORTS_FTRACE_OPS 1
@@ -17,6 +30,8 @@
#define HAVE_FUNCTION_GRAPH_RET_ADDR_PTR
#ifndef __ASSEMBLY__
+#include <asm/sections.h>
+
extern void mcount(void);
extern atomic_t modifying_ftrace_code;
extern void __fentry__(void);
@@ -24,9 +39,11 @@ extern void __fentry__(void);
static inline unsigned long f...
2017 Oct 04
28
x86: PIE support and option to extend KASLR randomization
These patches make the changes necessary to build the kernel as Position
Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
the top 2G of the virtual address space. It allows to optionally extend the
KASLR randomization range from 1G to 3G.
Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler
changes, PIE support and KASLR in general. Thanks to
2017 Oct 04
28
x86: PIE support and option to extend KASLR randomization
These patches make the changes necessary to build the kernel as Position
Independent Executable (PIE) on x86_64. A PIE kernel can be relocated below
the top 2G of the virtual address space. It allows to optionally extend the
KASLR randomization range from 1G to 3G.
Thanks a lot to Ard Biesheuvel & Kees Cook on their feedback on compiler
changes, PIE support and KASLR in general. Thanks to
2013 Nov 15
23
[PATCH -tip RFC v2 00/22] kprobes: introduce NOKPROBE_SYMBOL() and general cleaning of kprobe blacklist
Currently the blacklist is maintained by hand in kprobes.c
which is separated from the function definition and is hard
to catch up the kernel update.
To solve this issue, I've tried to implement new
NOKPROBE_SYMBOL() macro for making kprobe blacklist at
build time. Since the NOKPROBE_SYMBOL() macros can be placed
right after the function is defined, it is easy to maintain.
This series
2013 Nov 15
23
[PATCH -tip RFC v2 00/22] kprobes: introduce NOKPROBE_SYMBOL() and general cleaning of kprobe blacklist
Currently the blacklist is maintained by hand in kprobes.c
which is separated from the function definition and is hard
to catch up the kernel update.
To solve this issue, I've tried to implement new
NOKPROBE_SYMBOL() macro for making kprobe blacklist at
build time. Since the NOKPROBE_SYMBOL() macros can be placed
right after the function is defined, it is easy to maintain.
This series
2013 Nov 20
28
[PATCH -tip v3 00/23] kprobes: introduce NOKPROBE_SYMBOL() and general cleaning of kprobe blacklist
Hi,
Here is the version 3 of NOKPORBE_SYMBOL series.
Currently the blacklist is maintained by hand in kprobes.c
which is separated from the function definition and is hard
to catch up the kernel update.
To solve this issue, I've introduced NOKPROBE_SYMBOL() macro
for making kprobe blacklist at build time. Since the
NOKPROBE_SYMBOL() macros can be placed right after the
function is defined
2013 Nov 20
28
[PATCH -tip v3 00/23] kprobes: introduce NOKPROBE_SYMBOL() and general cleaning of kprobe blacklist
Hi,
Here is the version 3 of NOKPORBE_SYMBOL series.
Currently the blacklist is maintained by hand in kprobes.c
which is separated from the function definition and is hard
to catch up the kernel update.
To solve this issue, I've introduced NOKPROBE_SYMBOL() macro
for making kprobe blacklist at build time. Since the
NOKPROBE_SYMBOL() macros can be placed right after the
function is defined