From: Wang Nan <wangnan0@huawei.com>
To: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: <tixy@linaro.org>, <linux@arm.linux.org.uk>,
<linux-kernel@vger.kernel.org>,
<linux-arm-kernel@lists.infradead.org>, <lizefan@huawei.com>
Subject: Re: [PATCH] kprobes: bugfix: checks kprobes_all_disarmed in unoptimized_kprobe().
Date: Mon, 19 Jan 2015 19:21:39 +0800 [thread overview]
Message-ID: <54BCE8C3.4080903@huawei.com> (raw)
In-Reply-To: <54BCC8C0.40706@hitachi.com>
On 2015/1/19 17:05, Masami Hiramatsu wrote:
> Hi Wang,
>
> I've found a problem on this patch, since kprobes calls unoptioize_kprobe
> with kprobes_all_disarmed=true when trying to disable all kprobes, this
> cause a serious problem.
>
> Moreover, I couldn't reproduce your reported bug on my 3.19-rc4 kernel.
> Could you test it again?
>
I tested it again based on 3.19-rc5 and found that the problem still exists.
My testing is based on QEMU.
First I tested my kprobeopt for ARM, then on x86_64. The test results are pasted
at the bottom of this mail. Commands after 'gdb attaches to QEMU' is my actions
on a gdb console attached to QEMU; commands after 'inside virtual machine' is
what I do in Linux run under QEMU.
** ARM result **
------ gdb attaches to QEMU -------
(gdb) x/3i sys_open
0xc013619c <SyS_open>: mov r12, sp <--- *original insn*
0xc01361a0 <SyS_open+4>: push {r11, r12, lr, pc}
0xc01361a4 <SyS_open+8>: sub r11, r12, #4
------ inside virtual machine -------
# echo 'p:myprobe sys_open' > /sys/kernel/debug/tracing/kprobe_events
# echo 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe/enable
------ gdb attaches to QEMU -------
cpu_v7_do_idle () at /home/w00229757/kernel-hydrogen/arch/arm/mm/proc-v7.S:74
74 ret lr
(gdb) x/3i sys_open
0xc013619c <SyS_open>: b 0xbf000000 <--- *optimized*
0xc01361a0 <SyS_open+4>: push {r11, r12, lr, pc}
0xc01361a4 <SyS_open+8>: sub r11, r12, #4
(gdb) c
------ inside virtual machine -------
# echo 0 > /sys/kernel/debug/kprobes/enabled
------ gdb attaches to QEMU -------
cpu_v7_do_idle () at /home/w00229757/kernel-hydrogen/arch/arm/mm/proc-v7.S:74
74 ret lr
(gdb) x/3i sys_open
0xc013619c <SyS_open>: ; <UNDEFINED> instruction: 0xe7f001f8 <--- *BREAKPOINT*
0xc01361a0 <SyS_open+4>: push {r11, r12, lr, pc}
0xc01361a4 <SyS_open+8>: sub r11, r12, #4
(gdb) c
** x86_64 result **
------ gdb attaches to QEMU -------
(gdb) x/10i sys_open
0xffffffff81184fe0 <SyS_open>: data32 data32 data32 xchg %ax,%ax
0xffffffff81184fe5 <SyS_open+5>: push %rbp
0xffffffff81184fe6 <SyS_open+6>: movzwl %dx,%ecx
0xffffffff81184fe9 <SyS_open+9>: mov %esi,%edx
0xffffffff81184feb <SyS_open+11>: mov %rsp,%rbp
0xffffffff81184fee <SyS_open+14>: mov %rdi,%rsi
0xffffffff81184ff1 <SyS_open+17>: or $0x80,%dh
0xffffffff81184ff4 <SyS_open+20>: mov $0xffffff9c,%edi
0xffffffff81184ff9 <SyS_open+25>: callq 0xffffffff81184da0 <do_sys_open>
0xffffffff81184ffe <SyS_open+30>: pop %rbp
(gdb) c
Continuing
------ inside virtual machine -------
# echo 'p:myprobe sys_open+20' > /sys/kernel/debug/tracing/kprobe_events
# echo 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe/enable
------ gdb attaches to QEMU -------
(gdb) x/10i sys_open
0xffffffff81184fe0 <SyS_open>: data32 data32 data32 xchg %ax,%ax
0xffffffff81184fe5 <SyS_open+5>: push %rbp
0xffffffff81184fe6 <SyS_open+6>: movzwl %dx,%ecx
0xffffffff81184fe9 <SyS_open+9>: mov %esi,%edx
0xffffffff81184feb <SyS_open+11>: mov %rsp,%rbp
0xffffffff81184fee <SyS_open+14>: mov %rdi,%rsi
0xffffffff81184ff1 <SyS_open+17>: or $0x80,%dh
0xffffffff81184ff4 <SyS_open+20>: jmpq 0xffffffffa0002000 <--- *optimized*
0xffffffff81184ff9 <SyS_open+25>: callq 0xffffffff81184da0 <do_sys_open>
0xffffffff81184ffe <SyS_open+30>: pop %rbp
(gdb) c
Continuing.
------ inside virtual machine -------
# echo 0 > /sys/kernel/debug/kprobes/enabled
------ gdb attaches to QEMU -------
(gdb) x/10i sys_open
0xffffffff81184fe0 <SyS_open>: data32 data32 data32 xchg %ax,%ax
0xffffffff81184fe5 <SyS_open+5>: push %rbp
0xffffffff81184fe6 <SyS_open+6>: movzwl %dx,%ecx
0xffffffff81184fe9 <SyS_open+9>: mov %esi,%edx
0xffffffff81184feb <SyS_open+11>: mov %rsp,%rbp
0xffffffff81184fee <SyS_open+14>: mov %rdi,%rsi
0xffffffff81184ff1 <SyS_open+17>: or $0x80,%dh
0xffffffff81184ff4 <SyS_open+20>: int3 <-- **BREAKPOINT**
0xffffffff81184ff5 <SyS_open+21>: pushfq
0xffffffff81184ff6 <SyS_open+22>: (bad)
(gdb)
next prev parent reply other threads:[~2015-01-19 11:24 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-05 12:32 [PATCH] kprobes: bugfix: force unoptimize when disable kprobes Wang Nan
2015-01-12 11:42 ` Masami Hiramatsu
2015-01-12 12:09 ` [PATCH] kprobes: bugfix: checks kprobes_all_disarmed in unoptimized_kprobe() Wang Nan
2015-01-12 12:52 ` Masami Hiramatsu
2015-01-19 3:04 ` Wang Nan
2015-01-19 9:05 ` Masami Hiramatsu
2015-01-19 11:21 ` Wang Nan [this message]
2015-01-19 12:45 ` Masami Hiramatsu
2015-01-19 12:59 ` Wang Nan
2015-01-20 2:51 ` [PATCH] kprobes: bugfix: makes kprobes/enabled works correctly for optimized kprobes Wang Nan
2015-01-20 7:12 ` Masami Hiramatsu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54BCE8C3.4080903@huawei.com \
--to=wangnan0@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=lizefan@huawei.com \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=tixy@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox