Received: by 10.213.65.68 with SMTP id h4csp594099imn; Wed, 28 Mar 2018 09:08:54 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/bcCbLU4p7cHB9Zj2DRySSRjpCmyhQ+qRWRNQnjNQ3z9c8OxeME2bErt/kVa2wS6jnR6TL X-Received: by 10.98.229.21 with SMTP id n21mr3459650pff.158.1522253334439; Wed, 28 Mar 2018 09:08:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522253334; cv=none; d=google.com; s=arc-20160816; b=gnreGBTf3NCkL8+CI6k5nQDA7Uh1Goa7egV7c7fj/AKcYNpIeiQ+ueOyUwpDkZDbmb 0BCF2aVPTypQP71el/KgVDdA8YWSlEfUDDQFVbI8DaikJN4V9mPQJz8yVoJVz/iyoXvd /fp6ROmrDFrwhe/j7SwmAfYyvcUQhTAcAvDSDfggFQ4DCxoCZvieQTpYDus7ZSn2bmub kzVtbd1jeigkt0+Fe/QM3ii8iQLOTr/SGX26g1jLiCR2TOlMzsxSmDpA5ra6CwZ7N0pk ePgiKdQfx/7WQKlPspiM+2C+y5lP5kE8/wS/ATlERNrQ8Af79EwDZh8JOwQE1a6xzQ4M Mf/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:arc-authentication-results; bh=CQdq24Zpthpf4+bFst9E5tegdcSzuWFcBCXd+vvr2ow=; b=ZOAd8dJtQdHTZSofy3HtBT9y1HxpKUfZ6GsJqI+e7Zj1nAQ3v4M0eujNENIJDYnVkS HIyvaBUPECuuNuYoUHhkf5ulOXarNDb6iEA28AWRRhuWml2pdPUxWU88FHV7Nmt418Ex gnGdgK0+OXudasP+X+DLyWPqgADd4dci8+iewZ5S5B1HO+XgHi0OhjZjZ6ih6kCdHeVT 2GGZWpiH4x8iP0+sKJ7LaexFD26qvvP+Do5VXZ7ZisMemDBeTSOUPWZd00dO+gwysVty M3hQytT+NnWabk/AboQs+U7DFJzRKTCxhdb8wU03DHLnK0tp/LhKC36dGGPytsJ0Elbi 0eiA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id bj1-v6si3822824plb.663.2018.03.28.09.08.40; Wed, 28 Mar 2018 09:08:54 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753743AbeC1OVw (ORCPT + 99 others); Wed, 28 Mar 2018 10:21:52 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:43062 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753539AbeC1OVe (ORCPT ); Wed, 28 Mar 2018 10:21:34 -0400 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id F2D4940704AE; Wed, 28 Mar 2018 14:21:33 +0000 (UTC) Received: from llong.com (dhcp-17-164.bos.redhat.com [10.18.17.164]) by smtp.corp.redhat.com (Postfix) with ESMTP id ABAD3200BCC5; Wed, 28 Mar 2018 14:21:33 +0000 (UTC) From: Waiman Long To: Ingo Molnar , Peter Zijlstra , Thomas Gleixner Cc: linux-kernel@vger.kernel.org, Davidlohr Bueso , Waiman Long Subject: [PATCH v4 2/2] locking/debug: Restructure the lock debugging menu Date: Wed, 28 Mar 2018 10:20:52 -0400 Message-Id: <1522246852-17501-3-git-send-email-longman@redhat.com> In-Reply-To: <1522246852-17501-1-git-send-email-longman@redhat.com> References: <1522246852-17501-1-git-send-email-longman@redhat.com> X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Wed, 28 Mar 2018 14:21:34 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Wed, 28 Mar 2018 14:21:34 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'longman@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Two config options in the lock debugging menu that are probably the most frequently used, as far as I am concerned, is the PROVE_LOCKING and LOCK_STAT. From a UI perspective, they should be front and center. So these two options are now moved to the top of the lock debugging menu. The DEBUG_WW_MUTEX_SLOWPATH option is also added to the PROVE_LOCKING umbrella. Signed-off-by: Waiman Long --- lib/Kconfig.debug | 146 ++++++++++++++++++++++++++++-------------------------- 1 file changed, 76 insertions(+), 70 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 6aad28c..dc9ffe2 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1034,6 +1034,79 @@ config DEBUG_PREEMPT menu "Lock Debugging (spinlocks, mutexes, etc...)" +config LOCK_DEBUGGING_SUPPORT + bool + depends on TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT + default y + +config PROVE_LOCKING + bool "Lock debugging: prove locking correctness" + depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT + select LOCKDEP + select DEBUG_SPINLOCK + select DEBUG_MUTEXES + select DEBUG_RT_MUTEXES if RT_MUTEXES + select DEBUG_RWSEMS if RWSEM_SPIN_ON_OWNER + select DEBUG_WW_MUTEX_SLOWPATH + select DEBUG_LOCK_ALLOC + select TRACE_IRQFLAGS + default n + help + This feature enables the kernel to prove that all locking + that occurs in the kernel runtime is mathematically + correct: that under no circumstance could an arbitrary (and + not yet triggered) combination of observed locking + sequences (on an arbitrary number of CPUs, running an + arbitrary number of tasks and interrupt contexts) cause a + deadlock. + + In short, this feature enables the kernel to report locking + related deadlocks before they actually occur. + + The proof does not depend on how hard and complex a + deadlock scenario would be to trigger: how many + participant CPUs, tasks and irq-contexts would be needed + for it to trigger. The proof also does not depend on + timing: if a race and a resulting deadlock is possible + theoretically (no matter how unlikely the race scenario + is), it will be proven so and will immediately be + reported by the kernel (once the event is observed that + makes the deadlock theoretically possible). + + If a deadlock is impossible (i.e. the locking rules, as + observed by the kernel, are mathematically correct), the + kernel reports nothing. + + NOTE: this feature can also be enabled for rwlocks, mutexes + and rwsems - in which case all dependencies between these + different locking variants are observed and mapped too, and + the proof of observed correctness is also maintained for an + arbitrary combination of these separate locking variants. + + For more details, see Documentation/locking/lockdep-design.txt. + +config LOCK_STAT + bool "Lock usage statistics" + depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT + select LOCKDEP + select DEBUG_SPINLOCK + select DEBUG_MUTEXES + select DEBUG_RT_MUTEXES if RT_MUTEXES + select DEBUG_LOCK_ALLOC + default n + help + This feature enables tracking lock contention points + + For more details, see Documentation/locking/lockstat.txt + + This also enables lock events required by "perf lock", + subcommand of perf. + If you want to use "perf lock", you also need to turn on + CONFIG_EVENT_TRACING. + + CONFIG_LOCK_STAT defines "contended" and "acquired" lock events. + (CONFIG_LOCKDEP defines "acquire" and "release" events.) + config DEBUG_RT_MUTEXES bool "RT Mutex debugging, deadlock detection" depends on DEBUG_KERNEL && RT_MUTEXES @@ -1060,7 +1133,7 @@ config DEBUG_MUTEXES config DEBUG_WW_MUTEX_SLOWPATH bool "Wait/wound mutex debugging: Slowpath testing" - depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT + depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT select DEBUG_LOCK_ALLOC select DEBUG_SPINLOCK select DEBUG_MUTEXES @@ -1084,7 +1157,7 @@ config DEBUG_RWSEMS config DEBUG_LOCK_ALLOC bool "Lock debugging: detect incorrect freeing of live locks" - depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT + depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT select DEBUG_SPINLOCK select DEBUG_MUTEXES select DEBUG_RT_MUTEXES if RT_MUTEXES @@ -1097,54 +1170,9 @@ config DEBUG_LOCK_ALLOC spin_lock_init()/mutex_init()/etc., or whether there is any lock held during task exit. -config PROVE_LOCKING - bool "Lock debugging: prove locking correctness" - depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT - select LOCKDEP - select DEBUG_SPINLOCK - select DEBUG_MUTEXES - select DEBUG_RT_MUTEXES if RT_MUTEXES - select DEBUG_RWSEMS if RWSEM_SPIN_ON_OWNER - select DEBUG_LOCK_ALLOC - select TRACE_IRQFLAGS - default n - help - This feature enables the kernel to prove that all locking - that occurs in the kernel runtime is mathematically - correct: that under no circumstance could an arbitrary (and - not yet triggered) combination of observed locking - sequences (on an arbitrary number of CPUs, running an - arbitrary number of tasks and interrupt contexts) cause a - deadlock. - - In short, this feature enables the kernel to report locking - related deadlocks before they actually occur. - - The proof does not depend on how hard and complex a - deadlock scenario would be to trigger: how many - participant CPUs, tasks and irq-contexts would be needed - for it to trigger. The proof also does not depend on - timing: if a race and a resulting deadlock is possible - theoretically (no matter how unlikely the race scenario - is), it will be proven so and will immediately be - reported by the kernel (once the event is observed that - makes the deadlock theoretically possible). - - If a deadlock is impossible (i.e. the locking rules, as - observed by the kernel, are mathematically correct), the - kernel reports nothing. - - NOTE: this feature can also be enabled for rwlocks, mutexes - and rwsems - in which case all dependencies between these - different locking variants are observed and mapped too, and - the proof of observed correctness is also maintained for an - arbitrary combination of these separate locking variants. - - For more details, see Documentation/locking/lockdep-design.txt. - config LOCKDEP bool - depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT + depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT select STACKTRACE select FRAME_POINTER if !MIPS && !PPC && !ARM_UNWIND && !S390 && !MICROBLAZE && !ARC && !SCORE && !X86 select KALLSYMS @@ -1153,28 +1181,6 @@ config LOCKDEP config LOCKDEP_SMALL bool -config LOCK_STAT - bool "Lock usage statistics" - depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT - select LOCKDEP - select DEBUG_SPINLOCK - select DEBUG_MUTEXES - select DEBUG_RT_MUTEXES if RT_MUTEXES - select DEBUG_LOCK_ALLOC - default n - help - This feature enables tracking lock contention points - - For more details, see Documentation/locking/lockstat.txt - - This also enables lock events required by "perf lock", - subcommand of perf. - If you want to use "perf lock", you also need to turn on - CONFIG_EVENT_TRACING. - - CONFIG_LOCK_STAT defines "contended" and "acquired" lock events. - (CONFIG_LOCKDEP defines "acquire" and "release" events.) - config DEBUG_LOCKDEP bool "Lock dependency engine debugging" depends on DEBUG_KERNEL && LOCKDEP -- 1.8.3.1