linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
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 -


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