Subject: Re: [PATCH v5 0/6] arm64: ftrace: fix incorrect output from stack
 tracer
To: Jungseok Lee <jungseoklee85@gmail.com>
References: <1446792285-1154-1-git-send-email-takahiro.akashi@linaro.org>
 <252DE845-D0C2-460C-8161-090ED08396A4@gmail.com>
Cc: catalin.marinas@arm.com, will.deacon@arm.com, rostedt@goodmis.org,
        broonie@kernel.org, david.griego@linaro.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
From: AKASHI Takahiro <takahiro.akashi@linaro.org>
Message-ID: <56415D50.40500@linaro.org>
Date: Tue, 10 Nov 2015 11:58:24 +0900
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <252DE845-D0C2-460C-8161-090ED08396A4@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2809
Lines: 65

On 11/09/2015 11:24 PM, Jungseok Lee wrote:
> On Nov 6, 2015, at 3:44 PM, AKASHI Takahiro wrote:
>
> Hi Akashi,
>
>> This is the fifth patch series for fixing stack tracer on arm64.
>> The original issue was reported by Jungseok[1], and then I found more
>> issues[2].
>>
>> We don't have to care about the original issue because the root cause
>> (patch "ARM64: unwind: Fix PC calculation") has been reverted in v4.3.
>>
>> I address here all the issues and implement fixes described in [2] except
>> for interrupt-triggered problems(II-3) and leaf function(II-5).  Recent
>> discussions[3] about introducing a dedicated interrupt stack suggests that
>> we may avoid walking through from an interrupt stack to a process stack.
>> (So interrupt-stack patch is a prerequisite.)
>>
>> Basically,
>> patch1 is a proactive improvement of function_graph tracer.
>> patch2 corresponds to II-4(functions under function_graph tracer).
>> patch3, 4 and 5 correspond to II-1(slurping stack) and II-2(differences
>> between x86 and arm64).
>> patch6 is a function prologue analyzer test. This won't attest
>> the correctness of the functionality, but it can suggest that all
>> the traced functions are treated properly by this function.
>> (Please note that patch3 has already been queued in Steven's for-next.)
>>
>> I tested the code with v4.3 + Jungseok's patch v5[4].
>
> I've played this series with IRQ stack patch and it works well at least
> on my system! In addition to this condition, I've run these changes without
> IRQ stack since it is in progress. I could observe a single strange behavior,
> minus stack size around elX_irq. Am I missing something?

You saw the result like:
  ...
  13)     4336      64   gic_handle_irq+0x5c/0xa4
  14)     4272     576   el1_irq+0x68/0xd8
  15)     3696    -160   smc_hardware_send_pkt+0x278/0x42c

This is the most difficult problem that I mentioned in II-3 of [1] and tried to fix.
For example, smc_hardware_send_pkt is NOT the function interrupted, but
_raw_spin_unlock_irqstore which is called at '+0x278/0x42c' is.
Giving a *perfect* solution against it is quite tough (and complicated).
Since you have introduced interrupt stack and even on x86 an interrupt stack is
not supported, I removed related patches.

-Takahiro AKASHI

> My reproduction scenario is simple.
>
>    $ sudo echo 1 > /proc/sys/kernel/stack_trace_enabled
>    $ sudo echo function_graph > /sys/kernel/debug/tracing/current_tracer
>    $ [ Run any workload ]
>    $ sudo cat /sys/kernel/debug/tracing/stack_trace
>
> Best Regards
> Jungseok Lee
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/