[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20220926123416.6524c88b@gandalf.local.home>
Date: Mon, 26 Sep 2022 12:34:16 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Nadav Amit <nadav.amit@...il.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
LKML <linux-kernel@...r.kernel.org>, X86 ML <x86@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Borislav Petkov <bp@...en8.de>, Ingo Molnar <mingo@...hat.com>,
Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [RFC PATCH] x86/syscalls: allow tracing of __do_sys_[syscall]
functions
On Tue, 20 Sep 2022 18:31:24 -0700
Nadav Amit <nadav.amit@...il.com> wrote:
> Commit 45959ee7aa645 (“ftrace: Do not function trace inlined functions”)
> gives two reasons which correspond with what you were saying: (1)
> consistency and (2) function that should not be traced are mostly marked as
> inline.
>
> I am not sure I fully agree with the arguments, specifically the consistency
> (any function might be inlined and not traceable). But I am too afraid/lazy
> to cause damage and fix it. I will remove the inline and play a bit with the
> kernel to see how it behaves.
The main concern is two fold.
1) In the beginning, the function tracer was very susceptible to recursion
crashes (it's much more robust now), and depending on whether the compiler
decided to inline a function or not, would decide if a recursive function
would crash the kernel or not. It was a nightmare to debug!
2) Consistency. I was tired of getting bug reports that would say "hey
kernel X on machine M1 has function F available for tracing, but kernel X on
machine M2 does not have function F available". It was that the compiler
for M1 did not inline the function where it did for M2.
-- Steve
Powered by blists - more mailing lists