From: James Morse <james.morse@arm.com>
To: "Zhang, Lei" <zhang.lei@jp.fujitsu.com>
Cc: 'Mark Rutland' <mark.rutland@arm.com>,
"'catalin.marinas@arm.com'" <catalin.marinas@arm.com>,
"'will.deacon@arm.com'" <will.deacon@arm.com>,
"'linux-arm-kernel@lists.infradead.org'"
<linux-arm-kernel@lists.infradead.org>,
"'linux-kernel@vger.kernel.org'" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] arm64 memory accesses may cause undefined fault on Fujitsu-A64FX
Date: Tue, 22 Jan 2019 14:42:18 +0000 [thread overview]
Message-ID: <d8a8107c-cd31-2517-79df-2ebfbbedb7da@arm.com> (raw)
In-Reply-To: <8898674D84E3B24BA3A2D289B872026A6A2A2F44@G01JPEXMBKW03>
Hello,
On 22/01/2019 02:05, Zhang, Lei wrote:
> Mark Rutland wrote:
>> * How often does this fault occur?
> In my test, this fault occurs once every several times
> in the OS boot sequence, and after the completion of OS boot,
> this fault have never occurred.
> In my opinion, this fault rarely occurs
> after the completion of OS boot.
Can you share anything about why this is? You mention a hardware-condition
that is reset at exception entry....
>> I'm a bit surprised by the single retry. Is there any guarantee that a
>> thread will eventually stop delivering this fault code?
> I guarantee that a thread will stop delivering this
> fault code by the this patch.
> The hardware condition which cause this fault is
> reset at exception entry, therefore execution of at
> least one instruction is guaranteed by this single retry.
... so its possible to take this fault during kernel_entry when we've taken an irq?
This will overwrite the ELR and SPSR, (and possibly the FAR and ESR), meaning we've
lost that information and can't return to the point in the kernel that took the
irq.
If we try, we might end up spinning through the irq handler, as the ELR might
now point
to el1_irq's kernel_entry.
We can spot we took an exception from the entry text ... but all we can do then
is panic().
I'm not sure its worth working around this if its just a matter of time before this
happens. (you mention its less likely after boot, it would be good to know why...)
Thanks,
James
next prev parent reply other threads:[~2019-01-22 14:42 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-18 12:52 Zhang, Lei
2019-01-18 14:17 ` Mark Rutland
2019-01-22 2:05 ` Zhang, Lei
2019-01-22 14:42 ` James Morse [this message]
2019-01-22 15:23 ` Mark Rutland
2019-01-23 12:51 ` Zhang, Lei
2019-01-25 6:51 ` Zhang, Lei
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=d8a8107c-cd31-2517-79df-2ebfbbedb7da@arm.com \
--to=james.morse@arm.com \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=will.deacon@arm.com \
--cc=zhang.lei@jp.fujitsu.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
all inboxes | Powered by JetHome®