All of lore.kernel.org
 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: 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 #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4206 bytes --]

WARNING: multiple messages have this Message-ID (diff)
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 22:59 UTC|newest]

Thread overview: 30+ 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-11-30 23:47 ` Justin Chen
2023-12-01  9:12 ` Ard Biesheuvel
2023-12-01  9:12   ` Ard Biesheuvel
2023-12-01 17:25   ` Justin Chen
2023-12-01 17:25     ` Justin Chen
2023-12-01 18:07     ` Steven Rostedt
2023-12-01 18:07       ` Steven Rostedt
2023-12-01 22:59       ` Justin Chen [this message]
2023-12-01 22:59         ` Justin Chen
2023-12-02  6:53         ` Ard Biesheuvel
2023-12-02  6:53           ` Ard Biesheuvel
2023-12-02  8:49           ` Justin Chen
2023-12-02  8:49             ` Justin Chen
2023-12-02  9:26             ` Ard Biesheuvel
2023-12-02  9:26               ` Ard Biesheuvel
2023-12-02 17:49               ` Justin Chen
2023-12-02 17:49                 ` Justin Chen
2023-12-01 18:22   ` Russell King (Oracle)
2023-12-01 18:22     ` Russell King (Oracle)
2024-05-27  7:43 ` Thorsten Scherer
2024-05-27  7:43   ` Thorsten Scherer
2024-05-27  7:56   ` Russell King (Oracle)
2024-05-27  7:56     ` Russell King (Oracle)
2024-05-27 12:28     ` Uwe Kleine-König
2024-05-27 12:28       ` Uwe Kleine-König
2024-05-27 12:51       ` Russell King (Oracle)
2024-05-27 12:51         ` Russell King (Oracle)
2024-05-28  4:52         ` Thorsten Scherer
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.