Re: [PATCH -tip] locking: Move CONFIG_LOCK_EVENT_COUNTS into Kernel hacking section

From: Waiman Long
Date: Thu Aug 12 2021 - 15:42:25 EST


On 8/12/21 3:05 PM, Davidlohr Bueso wrote:
Ping?

On Mon, 29 Mar 2021, Davidlohr Bueso wrote:

It's a lot more intuitive to have it in the locking section of the kernel
hacking part rather than under "General architecture-dependent options".

Signed-off-by: Davidlohr Bueso <dbueso@xxxxxxx>
---
arch/Kconfig      | 9 ---------
lib/Kconfig.debug | 9 +++++++++
2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index ecfd3520b676..d6f9aeaaf9f2 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1113,15 +1113,6 @@ config HAVE_ARCH_PREL32_RELOCATIONS
config ARCH_USE_MEMREMAP_PROT
    bool

-config LOCK_EVENT_COUNTS
-    bool "Locking event counts collection"
-    depends on DEBUG_FS
-    help
-      Enable light-weight counting of various locking related events
-      in the system with minimal performance impact. This reduces
-      the chance of application behavior change because of timing
-      differences. The counts are reported via debugfs.
-
# Select if the architecture has support for applying RELR relocations.
config ARCH_HAS_RELR
    bool
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 2779c29d9981..76639ff5998c 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1401,6 +1401,15 @@ config DEBUG_LOCKING_API_SELFTESTS
      The following locking APIs are covered: spinlocks, rwlocks,
      mutexes and rwsems.

+config LOCK_EVENT_COUNTS
+    bool "Locking event counts collection"
+    depends on DEBUG_FS
+    help
+      Enable light-weight counting of various locking related events
+      in the system with minimal performance impact. This reduces
+      the chance of application behavior change because of timing
+      differences. The counts are reported via debugfs.
+
config LOCK_TORTURE_TEST
    tristate "torture tests for locking"
    depends on DEBUG_KERNEL
--
2.26.2


I have no objection to that.

Acked-by: Waiman Long <longman@xxxxxxxxxx>