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
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
Hi,
I am now working on an example to see if what I suggested earlier is
possible.
During this, I encountered a problem in Kprobes on x86 that prevents
placing them on the insns with %rip-relative addressing.
register_kprobe() returns -EINVAL in such cases because
__copy_instruction() returns 0
Hi,
I am now working on an example to see if what I suggested earlier is
possible.
During this, I encountered a problem in Kprobes on x86 that prevents
placing them on the insns with %rip-relative addressing.
register_kprobe() returns -EINVAL in such cases because
__copy_instruction() returns 0
> (2015/02/24 15:04), Eugene Shatokhin wrote:
24.02.2015 06:47, Masami Hiramatsu пишет:
No, that is not allowed. I mean, you can do anything you want to do
on your handler (enabling preemption/irq etc.) but the result may be
not safe (it can crash your kernel, but it's not a kprobes' bug).
(2015/02/24 15:04), Eugene Shatokhin wrote:
24.02.2015 06:47, Masami Hiramatsu пишет:
No, that is not allowed. I mean, you can do anything you want to do
on your handler (enabling preemption/irq etc.) but the result may be
not safe (it can crash your kernel, but it's not a kprobes' bug).
(2015/02/24 15:04), Eugene Shatokhin wrote:
> 24.02.2015 06:47, Masami Hiramatsu пишет:
>> No, that is not allowed. I mean, you can do anything you want to do
>> on your handler (enabling preemption/irq etc.) but the result may be
>> not safe (it can crash your kernel, but it's not a kprobes'
(2015/02/24 15:04), Eugene Shatokhin wrote:
24.02.2015 06:47, Masami Hiramatsu пишет:
No, that is not allowed. I mean, you can do anything you want to do
on your handler (enabling preemption/irq etc.) but the result may be
not safe (it can crash your kernel, but it's not a kprobes' bug).
24.02.2015 06:47, Masami Hiramatsu пишет:
No, that is not allowed. I mean, you can do anything you want to do
on your handler (enabling preemption/irq etc.) but the result may be
not safe (it can crash your kernel, but it's not a kprobes' bug).
Yes, that is why I am asking.
Actually, enable
Hello,
(2015/02/24 0:04), Eugene Shatokhin wrote:
> Hi,
>
>
> First of all, many thanks to the developers of Kprobes! I use both
> Kprobes and parts of their code a lot in my projects these days.
>
> As far as I can see, the pre-handlers of Kprobes run with interrupts and
> preemption
Hi,
First of all, many thanks to the developers of Kprobes! I use both
Kprobes and parts of their code a lot in my projects these days.
As far as I can see, the pre-handlers of Kprobes run with interrupts and
preemption disabled on the given CPU, at least on x86 without Kprobe
Hi,
First of all, many thanks to the developers of Kprobes! I use both
Kprobes and parts of their code a lot in my projects these days.
As far as I can see, the pre-handlers of Kprobes run with interrupts and
preemption disabled on the given CPU, at least on x86 without Kprobe
24.02.2015 06:47, Masami Hiramatsu пишет:
No, that is not allowed. I mean, you can do anything you want to do
on your handler (enabling preemption/irq etc.) but the result may be
not safe (it can crash your kernel, but it's not a kprobes' bug).
Yes, that is why I am asking.
Actually, enable
Hello,
(2015/02/24 0:04), Eugene Shatokhin wrote:
Hi,
First of all, many thanks to the developers of Kprobes! I use both
Kprobes and parts of their code a lot in my projects these days.
As far as I can see, the pre-handlers of Kprobes run with interrupts and
preemption disabled on
14 matches
Mail list logo
