lkml.org 
[lkml]   [2015]   [Mar]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Kprobes: pre-handler with interrupts enabled - is it possible?
Hello,

It took a while to properly implement the technique I wrote about
earlier but I have prepared a working example. Initially, I did not
reset the Kprobe properly and that caused difficult-to-debug problems.
Anyway, it works now.

In this example, Kprobes are used to execute my functions before and
after the insn of interest, in the same context as the insn w.r.t. the
interrupts and the preemption. There are some drawbacks and tricky
points, but still.

I tested this code on my simple modules as well as on the network
drivers (atl1c, e1000e, e1000) in Ubuntu 14.04 and ROSA R5 (x86, both 32
and 64-bit).

If you are interested, the source code is here:
https://abf.io/spectre/kernel-examples#?path=kprobe_lite. Most of the
logic is in module.c, the details are in Readme.txt.

I will try now to reimplement the relevant parts of our RaceHound system
using the Kprobes and the technique from the example.

By the way, while working on that code, I found that Kprobes consider
the following insns as not boostable (can_boost() in
arch/x86/kernel/kprobes/core.c):

* opcodes c0, c1, d0 - d3 with ModRM.reg != 110(b): ROL, ROR, RCL, RCR,
SHL/SAL, SHR, SAR (Grp 2-1A)
* opcodes f6 and f7 with ModRM.reg != 001(b): TEST, NOT, NEG, MUL, IMUL,
DIV, IDIV (Grp 3-1A)
* opcodes fe and ff with ModRM.reg being 000(b) or 001(b): INC, DEC (Grp
4-1A and 5-1A)
* opcode 0f c7 with ModRM.reg == 001(b): CMPXCHG8B, CMPXCHG16B.

Not sure why Kprobes do so.

Regards,
Eugene



\
 
 \ /
  Last update: 2015-03-22 18:41    [W:4.008 / U:0.608 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site