linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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;
}

  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).