From: Baruch Siach <baruch@tkos.co.il>
To: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm64/traps: show fault address in exception trace
Date: Wed, 30 Apr 2025 07:46:32 +0300 [thread overview]
Message-ID: <874iy62r4n.fsf@tarshish> (raw)
In-Reply-To: <20250429153352.GA26610@willie-the-truck> (Will Deacon's message of "Tue, 29 Apr 2025 16:33:53 +0100")
Hi Will,
On Tue, Apr 29 2025, Will Deacon wrote:
> On Tue, Apr 29, 2025 at 10:15:24AM +0300, Baruch Siach wrote:
>> The FAR (fault address) register provides useful information when
>> debugging an unhandled exception.
>>
>> Signed-off-by: Baruch Siach <baruch@tkos.co.il>
>> ---
>> arch/arm64/kernel/traps.c | 11 ++++++-----
>> 1 file changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
>> index 4e26bd356a48..14eb598e33a7 100644
>> --- a/arch/arm64/kernel/traps.c
>> +++ b/arch/arm64/kernel/traps.c
>> @@ -239,7 +239,7 @@ void die(const char *str, struct pt_regs *regs, long err)
>> make_task_dead(SIGSEGV);
>> }
>>
>> -static void arm64_show_signal(int signo, const char *str)
>> +static void arm64_show_signal(int signo, const char *str, unsigned long far)
>> {
>> static DEFINE_RATELIMIT_STATE(rs, DEFAULT_RATELIMIT_INTERVAL,
>> DEFAULT_RATELIMIT_BURST);
>> @@ -256,6 +256,7 @@ static void arm64_show_signal(int signo, const char *str)
>> pr_info("%s[%d]: unhandled exception: ", tsk->comm, task_pid_nr(tsk));
>> if (esr)
>> pr_cont("%s, ESR 0x%016lx, ", esr_get_class_string(esr), esr);
>> + pr_cont("FAR 0x%016lx, ", far);
>
> Are you sure the FAR is always valid here? For example, if we're delivering
> a SIGILL due to an undefined instruction.
A user interested in hardware exception information should be in a
position to know whether this information is valid. But I guess that FAR
can't be valid when ESR isn't valid either.
> Also, once you have the PC and the registers (both of which we print),
> it's not too hard to dig the instruction out of the binary and figure out
> the faulting address that way.
I find FAR helpful to confirm the analysis of the instruction being
executed and its operands. The cost for adding this bit of information
isn't huge, I think.
Thanks for your review,
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.52.368.4656, http://www.tkos.co.il -
prev parent reply other threads:[~2025-04-30 4:48 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-29 7:15 [PATCH] arm64/traps: show fault address in exception trace Baruch Siach
2025-04-29 15:33 ` Will Deacon
2025-04-30 4:46 ` Baruch Siach [this message]
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=874iy62r4n.fsf@tarshish \
--to=baruch@tkos.co.il \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--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).