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