linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Justin Chen <justin.chen@broadcom.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	mhiramat@kernel.org, mark.rutland@arm.com, linux@armlinux.org.uk,
	linux-trace-kernel@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Florian Fainelli <florian.fainelli@broadcom.com>,
	Doug Berger <doug.berger@broadcom.com>
Subject: Re: ARM Ftrace Function Graph Fails With UNWINDER_FRAME_POINTER
Date: Fri, 1 Dec 2023 14:59:45 -0800	[thread overview]
Message-ID: <4597db06-dabc-4bb2-9f24-bd30e07ff86d@broadcom.com> (raw)
In-Reply-To: <20231201130702.2824115c@gandalf.local.home>


[-- Attachment #1.1: Type: text/plain, Size: 1780 bytes --]



On 12/1/23 10:07 AM, Steven Rostedt wrote:
> On Fri, 1 Dec 2023 09:25:59 -0800
> Justin Chen <justin.chen@broadcom.com> wrote:
> 
>>> It appears the sub instruction at 0x6dd0 correctly accounts for the
>>> extra 8 bytes, so the frame pointer is valid. So it is our assumption
>>> that there are no gaps between the stack frames is invalid.
>>
>> Thanks for the assistance. The gap between the stack frame depends on
>> the function. Most do not have a gap. Some have 8 (as shown above), some
>> have 12. A single assumption here is not going to work. I'm having a
>> hard time finding out the reasoning for this gap. I tried disabling a
>> bunch of gcc flags as well as -O2 and the gap still exists.
> 
> That code was originally added because of some strange things that gcc did
> with mcount (for example, it made a copy of the stack frame that it passed
> to mcount, where the function graph tracer replaced the copy of the return
> stack making the shadow stack go out of sync and crash). This was very hard
> to debug and I added this code to detect it if it happened again.
> 
> Well it's been over a decade since that happened (2009).
> 
>    71e308a239c09 ("function-graph: add stack frame test")
> 
> I'm happy assuming that the compiler folks are aware of our tricks with
> hijacking return calls and I don't expect it to happen again. We can just
> rip out those checks. That is, if it's only causing false positives, I
> don't think it's worth keeping around.
> 
> Has it detected any real issues on the Arm platforms?
> 
> -- Steve

I am not familiar enough to make a call. But from my limited testing 
with ARM, I didn't see any issues. If you would like me to, I can submit 
a patch to remove the check entirely. Or maybe only disable it for ARM?

Thanks,
Justin

[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4206 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-12-01 23:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-30 23:47 ARM Ftrace Function Graph Fails With UNWINDER_FRAME_POINTER Justin Chen
2023-12-01  9:12 ` Ard Biesheuvel
2023-12-01 17:25   ` Justin Chen
2023-12-01 18:07     ` Steven Rostedt
2023-12-01 22:59       ` Justin Chen [this message]
2023-12-02  6:53         ` Ard Biesheuvel
2023-12-02  8:49           ` Justin Chen
2023-12-02  9:26             ` Ard Biesheuvel
2023-12-02 17:49               ` Justin Chen
2023-12-01 18:22   ` Russell King (Oracle)
2024-05-27  7:43 ` Thorsten Scherer
2024-05-27  7:56   ` Russell King (Oracle)
2024-05-27 12:28     ` Uwe Kleine-König
2024-05-27 12:51       ` Russell King (Oracle)
2024-05-28  4:52         ` Thorsten Scherer

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=4597db06-dabc-4bb2-9f24-bd30e07ff86d@broadcom.com \
    --to=justin.chen@broadcom.com \
    --cc=ardb@kernel.org \
    --cc=doug.berger@broadcom.com \
    --cc=florian.fainelli@broadcom.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mark.rutland@arm.com \
    --cc=mhiramat@kernel.org \
    --cc=rostedt@goodmis.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).