From: Jungseok Lee <jungseoklee85@gmail.com>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>
Cc: catalin.marinas@arm.com, will.deacon@arm.com,
james.morse@arm.com, mark.rutland@arm.com, broonie@kernel.org,
david.griego@linaro.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2 1/2] arm64: revamp unwind_frame for interrupt stack
Date: Wed, 21 Oct 2015 21:14:30 +0900 [thread overview]
Message-ID: <B71E493E-1AAC-4BEF-93CF-2039FE5629B4@gmail.com> (raw)
In-Reply-To: <562732FC.7010306@linaro.org>
[Only Akashi and James]
On Oct 21, 2015, at 3:38 PM, AKASHI Takahiro wrote:
Hi Akashi and James,
Am I the only person who have experienced kernel panic with this series?
I have observed NULL pointer kernel panic with the following two ways.
- $ sudo echo c > /proc/sysrq-trigger
- perf record -e mem:[address of do_softirq]:x -ag -- sleep 2
The kernel panic is triggered when the last stack frame of swapper is unwound.
At that time, the value of fp, low, high is 0, 0, 0, respectively.
My tree includes "Synchronise dump_backtrace() with perf call chain" patch
which is queued into for-next/core.
Best Regards
Jungseok Lee
> On 10/20/2015 10:26 PM, Jungseok Lee wrote:
>> On Oct 20, 2015, at 5:00 PM, AKASHI Takahiro wrote:
>>> This patch allows unwind_frame() to traverse from interrupt stack
>>> to process stack correctly by having a dummy stack frame for irq
>>> exception entry created at its prologue.
>>>
>>> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
>>> ---
>>> arch/arm64/kernel/entry.S | 22 ++++++++++++++++++++--
>>> arch/arm64/kernel/stacktrace.c | 14 +++++++++++++-
>>> 2 files changed, 33 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>>> index c8e0bcf..779f807 100644
>>> --- a/arch/arm64/kernel/entry.S
>>> +++ b/arch/arm64/kernel/entry.S
>>> @@ -186,8 +186,26 @@ alternative_endif
>>> and x23, x23, #~(IRQ_STACK_SIZE - 1)
>>> cmp x20, x23 // check irq re-enterance
>>> mov x19, sp
>>> - csel x23, x19, x24, eq // x24 = top of irq stack
>>> - mov sp, x23
>>> + beq 1f
>>> + mov sp, x24 // x24 = top of irq stack
>>> + stp x29, x19, [sp, #-16]! // for sanity check
>>> + stp x29, x22, [sp, #-16]! // dummy stack frame
>>> + mov x29, sp
>>> +1:
>>> + /*
>>> + * Layout of interrupt stack after this macro is invoked:
>>> + *
>>> + * | |
>>> + *-0x20+----------------+ <= dummy stack frame
>>> + * | fp | : fp on process stack
>>> + *-0x18+----------------+
>>> + * | lr | : return address
>>> + *-0x10+----------------+
>>> + * | fp (copy) | : for sanity check
>>> + * -0x8+----------------+
>>> + * | sp | : sp on process stack
>>> + * 0x0+----------------+
>>> + */
>>> .endm
>>>
>>> /*
>>> diff --git a/arch/arm64/kernel/stacktrace.c b/arch/arm64/kernel/stacktrace.c
>>> index 407991b..03611a1 100644
>>> --- a/arch/arm64/kernel/stacktrace.c
>>> +++ b/arch/arm64/kernel/stacktrace.c
>>> @@ -43,12 +43,24 @@ int notrace unwind_frame(struct stackframe *frame)
>>> low = frame->sp;
>>> high = ALIGN(low, THREAD_SIZE);
>>>
>>> - if (fp < low || fp > high - 0x18 || fp & 0xf)
>>> + if (fp < low || fp > high - 0x20 || fp & 0xf)
>>> return -EINVAL;
>>>
>>> frame->sp = fp + 0x10;
>>> frame->fp = *(unsigned long *)(fp);
>>> /*
>>> + * check whether we are going to walk trough from interrupt stack
>>> + * to process stack
>>> + * If the previous frame is the initial (dummy) stack frame on
>>> + * interrupt stack, frame->sp now points to just below the frame
>>> + * (dummy frame + 0x10).
>>> + * See entry.S
>>> + */
>>> +#define STACK_LOW(addr) round_down((addr), THREAD_SIZE)
>>> + if ((STACK_LOW(frame->sp) != STACK_LOW(frame->fp)) &&
>>> + (frame->fp == *(unsigned long *)frame->sp))
>>> + frame->sp = *((unsigned long *)(frame->sp + 8));
>>> + /*
>>> * -4 here because we care about the PC at time of bl,
>>> * not where the return will go.
>>> */
>>> --
>>> 1.7.9.5
>>
>> How about folding the following hunk into this patch?
>> The comment would be helpful for people to follow this code.
>
> Thanks.
> A frame pointer(x29) is a frame pointer, and I'm not sure that the comment is
> very useful.
> But it's much better than "fp on process stack" in my ascii-art.
>
> -Takahiro AKASHI
>
>> ----8<----
>>
>> diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
>> index f1303c5..0ff7db3 100644
>> --- a/arch/arm64/kernel/entry.S
>> +++ b/arch/arm64/kernel/entry.S
>> @@ -122,7 +122,8 @@
>> * x21 - aborted SP
>> * x22 - aborted PC
>> * x23 - aborted PSTATE
>> - */
>> + * x29 - aborted FP
>> + */
>> .endm
>>
>> .macro kernel_exit, el
>>
>> ----8<----
>>
>> Best Regards
>> Jungseok Lee
>>
next prev parent reply other threads:[~2015-10-21 12:14 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-20 8:00 [PATCH v2 0/2] arm64: " AKASHI Takahiro
2015-10-20 8:00 ` [PATCH v2 1/2] arm64: revamp " AKASHI Takahiro
2015-10-20 13:26 ` Jungseok Lee
2015-10-21 6:38 ` AKASHI Takahiro
2015-10-21 12:14 ` Jungseok Lee [this message]
2015-10-21 12:16 ` Jungseok Lee
2015-10-20 8:00 ` [PATCH v2 2/2] arm64: fix dump_backtrace() to show correct pt_regs at interrupt AKASHI Takahiro
2015-10-21 11:32 ` Jungseok Lee
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=B71E493E-1AAC-4BEF-93CF-2039FE5629B4@gmail.com \
--to=jungseoklee85@gmail.com \
--cc=broonie@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=david.griego@linaro.org \
--cc=james.morse@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=takahiro.akashi@linaro.org \
--cc=will.deacon@arm.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®