From: Marc Zyngier <marc.zyngier@arm.com>
To: Will Deacon <will.deacon@arm.com>, linux-eng@arm.com
Cc: catalin.marinas@arm.com, stable@vger.kernel.org
Subject: Re: [PATCH 1/3] arm64: debug: unmask PSTATE.D earlier
Date: Tue, 19 Jul 2016 14:00:12 +0100 [thread overview]
Message-ID: <578E245C.9010202@arm.com> (raw)
In-Reply-To: <1468927195-24468-1-git-send-email-will.deacon@arm.com>
On 19/07/16 12:19, Will Deacon wrote:
> Clearing PSTATE.D is one of the requirements for generating a debug
> exception. The arm64 booting protocol requires that PSTATE.D is set,
> since many of the debug registers (for example, the hw_breakpoint
> registers) are UNKNOWN out of reset and could potentially generate
> spurious, fatal debug exceptions in early boot code if PSTATE.D was
> clear. Once the debug registers have been safely initialised, PSTATE.D
> is cleared, however this is currently broken for two reasons:
>
> (1) The boot CPU clears PSTATE.D in a postcore_initcall and secondary
> CPUs clear PSTATE.D in secondary_start_kernel. Since the initcall
> runs after SMP (and the scheduler) have been initialised, there is
> no guarantee that it is actually running on the boot CPU. In this
> case, the boot CPU is left with PSTATE.D set and is not capable of
> generating debug exceptions.
>
> (2) In a preemptible kernel, we may explicitly schedule on the IRQ
> return path to EL1. If an IRQ occurs with PSTATE.D set in the idle
> thread, then we may schedule the kthread_init thread, run the
> postcore_initcall to clear PSTATE.D and then context switch back
> to the idle thread before returning from the IRQ. The exception
> return patch will then restore PSTATE.D from the stack, and set it
> again.
>
> This patch fixes the problem by moving the clearing of PSTATE.D earlier
> to proc.S. This has the desirable effect of clearing it in one place for
> all CPUs, long before we have to worry about the scheduler or any
> exception handling. We ensure that the previous reset of MDSCR_EL1 has
> completed before unmasking the exception, so that any spurious
> exceptions resulting from UNKNOWN debug registers are not generated.
>
> Without this patch applied, the kprobes selftests have been seen to fail
> under KVM, where we end up attempting to step the OOL instruction buffer
> with PSTATE.D set and therefore fail to complete the step.
>
> Cc: <stable@vger.kernel.org>
> Reported-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
Gave it a spin on both Juno and Seattle, both host and KVM guest, and
everything went smoothly, so:
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
Thanks,
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2016-07-19 13:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-07-19 11:19 [PATCH 1/3] arm64: debug: unmask PSTATE.D earlier Will Deacon
2016-07-19 12:30 ` Mark Rutland
2016-07-19 13:00 ` Marc Zyngier [this message]
2016-07-19 13:05 ` Robin Murphy
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=578E245C.9010202@arm.com \
--to=marc.zyngier@arm.com \
--cc=catalin.marinas@arm.com \
--cc=linux-eng@arm.com \
--cc=stable@vger.kernel.org \
--cc=will.deacon@arm.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 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.