From: Oleg Nesterov <oleg@redhat.com>
To: Andrey Wagin <avagin@gmail.com>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andy Lutomirski <luto@amacapital.net>,
Cyrill Gorcunov <gorcunov@openvz.org>,
"criu@openvz.org" <criu@openvz.org>,
kvm@vger.kernel.org
Subject: Re: x86: Hardware breakpoints are not always triggered
Date: Thu, 28 Jan 2016 23:01:12 +0100 [thread overview]
Message-ID: <20160128220112.GA21390@redhat.com> (raw)
In-Reply-To: <20160128205327.GA19931@redhat.com>
On 01/28, Oleg Nesterov wrote:
>
> On 01/28, Andrey Wagin wrote:
> >
> > We use hardware breakpoints in CRIU and we found that sometimes we set
> > a break-point, but a process doesn't stop on it.
>
> reproduced, and this certainly looks like kvm bug to me.
>
> > The reproducer uses a different break-point address if it is executed
> > with arguments than when it executed without arguments.
>
> IOW, multiple processes running in parallel use the same debug register db0
> but different address. And it seems that set_debugreg(address, 0) sometime
> doesn't work in the guest kernel.
>
> I think I verified the following:
>
> - debug registers look always correct as it seen by the guest.
> I used get_debugreg() to dump them after the task misses bp.
>
> - do_debug() was not called in this case.
>
> - finally, it seems that the host has the wrong value in db0
> set by another process.
>
> I modified your test-case so that child2() calls child() when
> it detects the missed bp, and this does trigger do_debug/etc
> while it should not.
See another test-case below.
I am running "./bp 0 1" on the host and "./bp 14 15" under QEMU, this immediately
leads to
ERR!! hit wrong bp 0 != 14
ERR!! hit wrong bp 0 != 14
ERR!! hit wrong bp 0 != 14
ERR!! hit wrong bp 1 != 14
...
Oleg.
-------------------------------------------------------------------------------
#include <unistd.h>
#include <signal.h>
#include <stdlib.h>
#include <stdio.h>
#include <sys/wait.h>
#include <sys/ptrace.h>
#include <sys/user.h>
#include <asm/debugreg.h>
#include <assert.h>
#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
unsigned long encode_dr7(int drnum, int enable, unsigned int type, unsigned int len)
{
unsigned long dr7;
dr7 = ((len | type) & 0xf)
<< (DR_CONTROL_SHIFT + drnum * DR_CONTROL_SIZE);
if (enable)
dr7 |= (DR_GLOBAL_ENABLE << (drnum * DR_ENABLE_SIZE));
return dr7;
}
int write_dr(int pid, int dr, unsigned long val)
{
return ptrace(PTRACE_POKEUSER, pid,
offsetof (struct user, u_debugreg[dr]),
val);
}
void set_bp(pid_t pid, void *addr)
{
unsigned long dr7;
assert(write_dr(pid, 0, (long)addr) == 0);
dr7 = encode_dr7(0, 1, DR_RW_EXECUTE, DR_LEN_1);
assert(write_dr(pid, 7, dr7) == 0);
}
void *get_rip(int pid)
{
return (void*)ptrace(PTRACE_PEEKUSER, pid,
offsetof(struct user, regs.rip), 0);
}
void test(int nr)
{
void *bp_addr = &&label + nr, *bp_hit;
int pid;
printf("test bp %d\n", nr);
assert(nr < 16); // see 16 asm nops below
pid = fork();
if (!pid) {
assert(ptrace(PTRACE_TRACEME, 0,0,0) == 0);
kill(getpid(), SIGSTOP);
for (;;) {
label: asm (
"nop; nop; nop; nop;"
"nop; nop; nop; nop;"
"nop; nop; nop; nop;"
"nop; nop; nop; nop;"
);
}
}
assert(pid == wait(NULL));
set_bp(pid, bp_addr);
for (;;) {
assert(ptrace(PTRACE_CONT, pid, 0, 0) == 0);
assert(pid == wait(NULL));
bp_hit = get_rip(pid);
if (bp_hit != bp_addr)
fprintf(stderr, "ERR!! hit wrong bp %ld != %d\n",
bp_hit - &&label, nr);
}
}
int main(int argc, const char *argv[])
{
while (--argc) {
int nr = atoi(*++argv);
if (!fork())
test(nr);
}
while (wait(NULL) > 0)
;
return 0;
}
next prev parent reply other threads:[~2016-01-28 22:01 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-28 8:31 x86: Hardware breakpoints are not always triggered Andrey Wagin
2016-01-28 11:01 ` Jan Kiszka
2016-01-28 20:53 ` Oleg Nesterov
2016-01-28 21:29 ` Paolo Bonzini
2016-01-28 22:01 ` Oleg Nesterov [this message]
2016-01-28 21:33 ` Paolo Bonzini
2016-01-28 22:42 ` Andrey Wagin
2016-01-29 22:21 ` [CRIU] " Andrew Vagin
2016-01-31 11:01 ` Paolo Bonzini
2016-02-03 18:18 ` Nadav Amit
2016-02-03 23:32 ` Nadav Amit
2016-02-04 11:28 ` Paolo Bonzini
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=20160128220112.GA21390@redhat.com \
--to=oleg@redhat.com \
--cc=avagin@gmail.com \
--cc=criu@openvz.org \
--cc=gorcunov@openvz.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
/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;
as well as URLs for NNTP newsgroup(s).