linux-kernel - [PATCH v2 2/3] compiler: inline does not imply notrace

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: <20230525210040.3637-3-namit@vmware.com>
Date:   Thu, 25 May 2023 14:00:39 -0700
From:   Nadav Amit <nadav.amit@...il.com>
To:     Steven Rostedt <rostedt@...dmis.org>,
        "Arnd Bergmann" <arnd@...db.de>,
        "Thomas Gleixner" <tglx@...utronix.de>
Cc:     linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
        linux-ia64@...r.kernel.org, linux-um@...ts.infradead.org,
        Linux-Arch <linux-arch@...r.kernel.org>, linux-mm@...ck.org,
        "Andy Lutomirski" <luto@...nel.org>,
        "Ingo Molnar" <mingo@...hat.com>,
        "Dave Hansen" <dave.hansen@...ux.intel.com>,
        "Borislav Petkov" <bp@...en8.de>, x86@...nel.org,
        Peter Zijlstra <peterz@...radead.org>,
        Nadav Amit <namit@...are.com>
Subject: [PATCH v2 2/3] compiler: inline does not imply notrace

From: Nadav Amit <namit@...are.com>

Functions that are marked as "inline" are currently also not tracable.
This limits tracing functionality for many functions for no reason.
Apparently, this has been done for two reasons.

First, as described in commit 5963e317b1e9d2a ("ftrace/x86: Do not
change stacks in DEBUG when calling lockdep"), it was intended to
prevent some functions that cannot be traced from being traced as these
functions were marked as inline (among others).

Yet, this change has been done a decade ago, and according to Steven
Rostedt, ftrace should have improved and hopefully resolved nested
tracing issues by now. Arguably, if functions that should be traced -
for instance since they are used during tracing - still exist, they
should be marked as notrace explicitly.

The second reason, which Steven raised, is that attaching "notrace" to
"inline" prevented tracing differences between different configs, which
caused various problem. This consideration is not very strong, and tying
"inline" and "notrace" does not seem very beneficial. The "inline"
keyword is just a hint, and many functions are currently not tracable
due to this reason.

Disconnect "inline" from "notrace".

Signed-off-by: Nadav Amit <namit@...are.com>
---
 include/linux/compiler_types.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 547ea1ff806e..bab3e25bbe3f 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -184,7 +184,7 @@ struct ftrace_likely_data {
  * of extern inline functions at link time.
  * A lot of inline functions can cause havoc with function tracing.
  */
-#define inline inline __gnu_inline __inline_maybe_unused notrace
+#define inline inline __gnu_inline __inline_maybe_unused

 /*
  * gcc provides both __inline__ and __inline as alternate spellings of
-- 
2.25.1