All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.