linux-kernel - Re: [PATCH v5 0/6] arm64: ftrace: fix incorrect output from stack tracer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <06B8BFC7-E3A5-4FF8-8897-27AD597D2E45@gmail.com>
Date:	Tue, 10 Nov 2015 22:32:47 +0900
From:	Jungseok Lee <jungseoklee85@...il.com>
To:	AKASHI Takahiro <takahiro.akashi@...aro.org>
Cc:	catalin.marinas@....com, will.deacon@....com, rostedt@...dmis.org,
	broonie@...nel.org, david.griego@...aro.org,
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 0/6] arm64: ftrace: fix incorrect output from stack tracer

On Nov 10, 2015, at 11:58 AM, AKASHI Takahiro wrote:

Hi Akashi,

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

Yes, that is what I've observed. I was not sure whether the behavior is related to
II-3, interrupted frame, or not. Thanks for clarification!

Best Regards
Jungseok Lee--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/