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 21:53:27 +0100	[thread overview]
Message-ID: <20160128205327.GA19931@redhat.com> (raw)
In-Reply-To: <CANaxB-wGTnLX=s9aVG4ziXVtsVn672Q4BmfEX12=398_XZdmqA@mail.gmail.com>

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.

Oleg.


  parent reply	other threads:[~2016-01-28 20:53 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 [this message]
2016-01-28 21:29   ` Paolo Bonzini
2016-01-28 22:01   ` Oleg Nesterov
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=20160128205327.GA19931@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.