From: Peter Zijlstra <peterz@infradead.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: Kyle Huey <me@kylehuey.com>,
open list <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
"maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)"
<x86@kernel.org>, Linus Torvalds <torvalds@linux-foundation.org>,
Robert O'Callahan <rocallahan@gmail.com>,
Alexandre Chartre <alexandre.chartre@oracle.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
Frederic Weisbecker <frederic@kernel.org>,
Paolo Bonzini <pbonzini@redhat.com>,
Sean Christopherson <sean.j.christopherson@intel.com>,
Masami Hiramatsu <mhiramat@kernel.org>,
Petr Mladek <pmladek@suse.com>,
Joel Fernandes <joel@joelfernandes.org>,
Steven Rostedt <rostedt@goodmis.org>,
Boris Ostrovsky <boris.ostrovsky@oracle.com>,
Juergen Gross <jgross@suse.com>, Brian Gerst <brgerst@gmail.com>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Daniel Thompson <daniel.thompson@linaro.org>
Subject: Re: [REGRESSION] x86/debug: After PTRACE_SINGLESTEP DR_STEP is no longer reported in dr6
Date: Tue, 27 Oct 2020 09:15:59 +0100 [thread overview]
Message-ID: <20201027081559.GI2628@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CALCETrXwS0CtPuX7AgUorrPDis7Czd_ngO1=FG0=VqGS8Ru+JA@mail.gmail.com>
On Mon, Oct 26, 2020 at 04:45:18PM -0700, Andy Lutomirski wrote:
> PeterZ, this new scheme of having handlers clear bits in dr6 to
> consume them and set bits in virtual_dr6 to send signals is
> incomprehensible -- there is no possible way to read traps.c and tell
> what the code does :(
IIRC, it was you who suggested it. Also the old code was equally
incomprehensible. Now it has actual semantics.
> I attached a test case. I'll make a real patch out of this in a bit.
> This passes on 5.8, and I haven't tested it yet on 5.10-rc1. The real
> patch will also test ICEBP, and I'm sure we'll be quite unhappy with
> the result of that.
> diff --git a/tools/testing/selftests/x86/single_step_syscall.c b/tools/testing/selftests/x86/single_step_syscall.c
> index 5a4c6e06872e..f6abefd4066e 100644
> --- a/tools/testing/selftests/x86/single_step_syscall.c
> +++ b/tools/testing/selftests/x86/single_step_syscall.c
> @@ -72,7 +72,6 @@ static unsigned char altstack_data[SIGSTKSZ];
> static void sigtrap(int sig, siginfo_t *info, void *ctx_void)
> {
> ucontext_t *ctx = (ucontext_t*)ctx_void;
> - unsigned long dr6 = info->si_code;
>
> if (get_eflags() & X86_EFLAGS_TF) {
> set_eflags(get_eflags() & ~X86_EFLAGS_TF);
> @@ -89,7 +88,10 @@ static void sigtrap(int sig, siginfo_t *info, void *ctx_void)
> (unsigned long)ctx->uc_mcontext.gregs[REG_IP]);
> }
>
> - printf("DR6 = 0x%lx\n", dr6);
> + if (info->si_code != TRAP_TRACE) {
> + printf("[FAIL]\tsi_code was 0x%lx; should have been TRAP_TRACE (0x%lx)\n", (unsigned long)info->si_code, (unsigned long)TRAP_TRACE);
> + _exit(1);
> + }
> }
That actually works (tested). Nothing here cares about the virtual_dr6 value.
Think of virtual_dr6 as the value used by ptrace_{get,set}_debugreg(6).
It (should) only contain bits that results from other ptrace() actions.
next prev parent reply other threads:[~2020-10-27 8:16 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-26 14:33 Kyle Huey
2020-10-26 15:55 ` Peter Zijlstra
2020-10-26 16:05 ` Peter Zijlstra
2020-10-26 16:14 ` Kyle Huey
2020-10-26 16:31 ` Peter Zijlstra
2020-10-26 16:55 ` Peter Zijlstra
2020-10-26 17:12 ` Kyle Huey
2020-10-26 17:17 ` Peter Zijlstra
2020-10-26 18:36 ` Kyle Huey
2020-10-26 23:30 ` Andy Lutomirski
2020-10-26 23:45 ` Andy Lutomirski
2020-10-27 8:15 ` Peter Zijlstra [this message]
2020-10-27 8:19 ` Peter Zijlstra
2020-10-27 18:00 ` Andy Lutomirski
2020-10-27 19:20 ` Peter Zijlstra
2020-10-27 9:08 ` Peter Zijlstra
2020-10-27 17:56 ` Peter Zijlstra
2020-10-26 16:08 ` Kyle Huey
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=20201027081559.GI2628@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=alexandre.chartre@oracle.com \
--cc=boris.ostrovsky@oracle.com \
--cc=brgerst@gmail.com \
--cc=daniel.thompson@linaro.org \
--cc=frederic@kernel.org \
--cc=jgross@suse.com \
--cc=joel@joelfernandes.org \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=me@kylehuey.com \
--cc=mhiramat@kernel.org \
--cc=paulmck@kernel.org \
--cc=pbonzini@redhat.com \
--cc=pmladek@suse.com \
--cc=rocallahan@gmail.com \
--cc=rostedt@goodmis.org \
--cc=sean.j.christopherson@intel.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.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
all inboxes | Powered by JetHome®