From: Xiaofei Tan <tanxiaofei@huawei.com>
To: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, James Morse <james.morse@arm.com>,
Dave Martin <Dave.Martin@arm.com>
Cc: Linuxarm <linuxarm@huawei.com>,
linux-arm-kernel@lists.infradead.org,
Shiju Jose <shiju.jose@huawei.com>
Subject: Question about SEA handling process happened in user space
Date: Mon, 30 Mar 2020 21:10:37 +0800 [thread overview]
Message-ID: <5E81EFCD.6020605@huawei.com> (raw)
Hi ALL
I'm a little confused about the handling process of SEA happened in user space.
Following the description of FnV bit of register ESR_ELx in ARMv8.4 SPEC,FAR is
valid only for synchronous External abort on a translation table walk.
But for this FAR valid scenario(attached code from line 684 to 687),
we send signal SIGKILL to kill process. For some other scenario, such as line 680,
FAR is not valid, but we send SIGBUS and transfer error address to process to try to do some recovery.
should it be an problem ?
FnV, bit [10]
FAR not Valid, for a synchronous External abort other than a synchronous External abort on a
translation table walk.
0b0 FAR is valid.
0b1 FAR is not valid, and holds an UNKNOWN value.
This field is only valid if the IFSC code is 0b010000. It is RES0 for all other aborts.
This field resets to an architecturally UNKNOWN value.
arch/arm64/mm/fault.c
663 static const struct fault_info fault_info[] = {
664 { do_bad, SIGKILL, SI_KERNEL, "ttbr address size fault" },
665 { do_bad, SIGKILL, SI_KERNEL, "level 1 address size fault" },
666 { do_bad, SIGKILL, SI_KERNEL, "level 2 address size fault" },
667 { do_bad, SIGKILL, SI_KERNEL, "level 3 address size fault" },
668 { do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 0 translation fault" },
669 { do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 1 translation fault" },
670 { do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 2 translation fault" },
671 { do_translation_fault, SIGSEGV, SEGV_MAPERR, "level 3 translation fault" },
672 { do_bad, SIGKILL, SI_KERNEL, "unknown 8" },
673 { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 1 access flag fault" },
674 { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 2 access flag fault" },
675 { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 3 access flag fault" },
676 { do_bad, SIGKILL, SI_KERNEL, "unknown 12" },
677 { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 1 permission fault" },
678 { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 2 permission fault" },
679 { do_page_fault, SIGSEGV, SEGV_ACCERR, "level 3 permission fault" },
680 { do_sea, SIGBUS, BUS_OBJERR, "synchronous external abort" },
681 { do_bad, SIGKILL, SI_KERNEL, "unknown 17" },
682 { do_bad, SIGKILL, SI_KERNEL, "unknown 18" },
683 { do_bad, SIGKILL, SI_KERNEL, "unknown 19" },
684 { do_sea, SIGKILL, SI_KERNEL, "level 0 (translation table walk)" },
685 { do_sea, SIGKILL, SI_KERNEL, "level 1 (translation table walk)" },
686 { do_sea, SIGKILL, SI_KERNEL, "level 2 (translation table walk)" },
687 { do_sea, SIGKILL, SI_KERNEL, "level 3 (translation table walk)" },
688 { do_sea, SIGBUS, BUS_OBJERR, "synchronous parity or ECC error" }, // Reserved when RAS is implemented
689 { do_bad, SIGKILL, SI_KERNEL, "unknown 25" },
690 { do_bad, SIGKILL, SI_KERNEL, "unknown 26" },
691 { do_bad, SIGKILL, SI_KERNEL, "unknown 27" },
692 { do_sea, SIGKILL, SI_KERNEL, "level 0 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
693 { do_sea, SIGKILL, SI_KERNEL, "level 1 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
694 { do_sea, SIGKILL, SI_KERNEL, "level 2 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
695 { do_sea, SIGKILL, SI_KERNEL, "level 3 synchronous parity error (translation table walk)" }, // Reserved when RAS is implemented
696 { do_bad, SIGKILL, SI_KERNEL, "unknown 32" },
--
thanks
tanxiaofei
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next reply other threads:[~2020-03-30 13:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-30 13:10 Xiaofei Tan [this message]
2020-03-30 16:49 ` Question about SEA handling process happened in user space James Morse
2020-03-31 9:41 ` Xiaofei Tan
2020-03-31 17:00 ` James Morse
2020-04-01 3:49 ` Xiaofei Tan
2020-04-07 16:37 ` James Morse
2020-04-09 8:42 ` Xiaofei Tan
2020-04-09 14:28 ` James Morse
2020-04-10 2:55 ` Xiaofei Tan
2020-04-16 13:27 ` James Morse
2020-04-18 10:49 ` Xiaofei Tan
2020-04-02 6:35 ` Xiaofei Tan
2020-04-07 16:37 ` James Morse
2020-04-09 9:17 ` Xiaofei Tan
2020-04-09 14:28 ` James Morse
2020-04-10 9:43 ` Xiaofei Tan
2020-04-16 13:50 ` James Morse
2020-04-18 11:25 ` Xiaofei Tan
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=5E81EFCD.6020605@huawei.com \
--to=tanxiaofei@huawei.com \
--cc=Dave.Martin@arm.com \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linuxarm@huawei.com \
--cc=shiju.jose@huawei.com \
--cc=will@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;
as well as URLs for NNTP newsgroup(s).