From: Andy Lutomirski <luto@kernel.org>
To: Eiichi Tsukata <devel@etsukata.com>
Cc: Andy Lutomirski <luto@kernel.org>,
Vegard Nossum <vegard.nossum@oracle.com>,
Peter Zijlstra <peterz@infradead.org>,
Thomas Gleixner <tglx@linutronix.de>,
Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux_lkml_grp@oracle.com, "H. Peter Anvin" <hpa@zytor.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Juergen Gross <jgross@suse.com>,
LKML <linux-kernel@vger.kernel.org>,
He Zhe <zhe.he@windriver.com>,
Joel Fernandes <joel@joelfernandes.org>
Subject: Re: [PATCH v3 0/6] Tracing vs CR2
Date: Sat, 20 Jul 2019 05:49:53 -0700 [thread overview]
Message-ID: <CALCETrUkEB89jkBzWg26Y0unCwgOWYT5da+OkbatUU_Bh97T8g@mail.gmail.com> (raw)
In-Reply-To: <98e20ed8-4032-09b5-e852-9f21df5c237c@etsukata.com>
On Fri, Jul 19, 2019 at 8:59 PM Eiichi Tsukata <devel@etsukata.com> wrote:
>
>
> On 2019/07/19 5:27, Andy Lutomirski wrote:
> > Hi all-
> >
> > I suspect that a bunch of the bugs you're all finding boil down to:
> >
> > - Nested debug exceptions could corrupt the outer exception's DR6.
> > - Nested debug exceptions in which *both* exceptions came from the
> > kernel were probably all kinds of buggy
> > - Data breakpoints in bad places in the kernel were bad news
> >
> > Could you give this not-quite-finished series a try?
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/
> >
>
> Though I'm still trying to find out other cases(other areas which could
> be buggy if we set hw breakpoints), as far as I tested, there is
> no problem so far.
>
> If I understand correctly, the call trace and the dr6 value will be:
>
> ====
>
> debug() // dr6: 0xffff4ff0, user_mode: 1
> TRACE_IRQS_OFF
> arch_stack_user_walk()
> debug() // dr6: 0xffff4ff1 == 0xffff4ff0 | 0xffff0ff1 ... (*)
> do_debug()
> WARN_ON_ONCE
> do_debug() // dr6: 0xffff0ff0(cleared in the above do_debug())
The dr6 register will indeed be cleared like this, but the dr6
variable should still be 0xffff4ff0.
>
> (*) :
> > * The Intel SDM says:
> > *
> > * Certain debug exceptions may clear bits 0-3. The remaining
> > * contents of the DR6 register are never cleared by the
> > * processor. To avoid confusion in identifying debug
> > * exceptions, debug handlers should clear the register before
> > * returning to the interrupted task.
>
> ====
>
> Note: printk() in do_debug() can cause infinite loop(printk() ->
> irq_disable() -> do_debug() -> printk() ...), so printk_deferred()
> was preferable.
>
Shouldn't that be fixed with my patches? It should only be able to
recurse two deep: do_debug() from user mode can indeed trip
breakpoints, but the next do_debug() will clear DR7 in paranoid_entry.
next prev parent reply other threads:[~2019-07-20 12:50 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-11 11:40 [PATCH v3 0/6] Tracing vs CR2 Peter Zijlstra
2019-07-11 11:40 ` [PATCH v3 1/6] x86/paravirt: Make read_cr2() CALLEE_SAVE Peter Zijlstra
2019-07-17 21:22 ` [tip:x86/urgent] " tip-bot for Peter Zijlstra
2019-07-11 11:40 ` [PATCH v3 2/6] x86/entry/32: Simplify common_exception Peter Zijlstra
2019-07-17 21:23 ` [tip:x86/urgent] " tip-bot for Peter Zijlstra
2019-07-11 11:40 ` [PATCH v3 3/6] x86/entry/64: Simplify idtentry a little Peter Zijlstra
2019-07-17 21:24 ` [tip:x86/urgent] " tip-bot for Peter Zijlstra
2019-07-11 11:40 ` [PATCH v3 4/6] x86/entry/64: Update comments and sanity tests for create_gap Peter Zijlstra
2019-07-17 21:25 ` [tip:x86/urgent] " tip-bot for Peter Zijlstra
2019-07-11 11:40 ` [PATCH v3 5/6] x86/mm, tracing: Fix CR2 corruption Peter Zijlstra
2019-07-17 21:25 ` [tip:x86/urgent] " tip-bot for Peter Zijlstra
2019-07-11 11:41 ` [PATCH v3 6/6] x86/entry/64: Remove TRACE_IRQS_*_DEBUG Peter Zijlstra
2019-07-11 14:45 ` Andy Lutomirski
2019-07-11 18:28 ` Peter Zijlstra
2019-07-16 19:33 ` [PATCH v3 0/6] Tracing vs CR2 Vegard Nossum
2019-07-16 21:51 ` Vegard Nossum
2019-07-17 1:02 ` Andy Lutomirski
2019-07-17 7:46 ` Vegard Nossum
2019-07-17 7:47 ` Peter Zijlstra
2019-07-17 9:37 ` Eiichi Tsukata
2019-07-18 20:27 ` Andy Lutomirski
2019-07-20 3:59 ` Eiichi Tsukata
2019-07-20 12:49 ` Andy Lutomirski [this message]
2019-07-20 14:23 ` Eiichi Tsukata
2019-07-17 8:07 ` Peter Zijlstra
2019-07-17 8:09 ` Vegard Nossum
2019-07-18 8:57 ` [PATCH] stacktrace: Force USER_DS for stack_trace_save_user() Peter Zijlstra
2019-07-18 13:21 ` Joel Fernandes
2019-07-18 14:52 ` [tip:core/urgent] " tip-bot for Peter Zijlstra
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=CALCETrUkEB89jkBzWg26Y0unCwgOWYT5da+OkbatUU_Bh97T8g@mail.gmail.com \
--to=luto@kernel.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=devel@etsukata.com \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=joel@joelfernandes.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_lkml_grp@oracle.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=vegard.nossum@oracle.com \
--cc=zhe.he@windriver.com \
/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).