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 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.
Thanks
Eiichi
