Displaying 7 results from an estimated 7 matches for "ftrace_addr".
2017 Oct 04
1
[RFC v3 20/27] x86/ftrace: Adapt function tracing for PIE support
...d = ftrace_nop_replace(size);
- return add_break(rec->ip, old);
+ return add_break(rec->ip, old, size);
}
static int add_breakpoints(struct dyn_ftrace *rec, int enable)
@@ -386,22 +438,23 @@ static int remove_breakpoint(struct dyn_ftrace *rec)
const unsigned char *nop;
unsigned long ftrace_addr;
unsigned long ip = rec->ip;
+ unsigned int size = MCOUNT_INSN_SIZE;
/* If we fail the read, just give up */
- if (probe_kernel_read(ins, (void *)ip, MCOUNT_INSN_SIZE))
+ if (probe_kernel_read(ins, (void *)ip, size))
return -EFAULT;
/* If this does not have a breakpoint, we are done...
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