From patchwork Mon Dec 11 03:50:17 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Theodore Ts'o X-Patchwork-Id: 10104115 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 6FEFC60235 for ; Mon, 11 Dec 2017 03:50:55 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2F7C8292DF for ; Mon, 11 Dec 2017 03:50:55 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 2233629329; Mon, 11 Dec 2017 03:50:55 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.8 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_HI,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 56BCD292DF for ; Mon, 11 Dec 2017 03:50:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752255AbdLKDux (ORCPT ); Sun, 10 Dec 2017 22:50:53 -0500 Received: from imap.thunk.org ([74.207.234.97]:57258 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752234AbdLKDuw (ORCPT ); Sun, 10 Dec 2017 22:50:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=Message-Id:Date:Subject:Cc:To:From:Sender:Reply-To: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=U6ECSF1CpysumB2yAtVI2GZJgcO0Hx/bQI2rZMwdt+s=; b=fhq8cgdqLorvJx7I7bdDnRSQWA OZqIpUy8l0blaNcMaYdsgHwRw87BhqDO1KLrBI7Rc36+NxIFDPA+BzRWauJ+s8TUlONXr87xh6OEu Rg1GaXKt23T1PPqGejtSF+K05onu9xSMbtohuWa9lfceqkV8yvFp3JVJiVt09x4us51Q=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1eOF6s-0005P5-Ks; Mon, 11 Dec 2017 03:50:30 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id 91F96C003F2; Sun, 10 Dec 2017 22:50:29 -0500 (EST) From: Theodore Ts'o To: Byungchul Park Cc: Theodore Ts'o , Linus Torvalds , Peter Zijlstra , Thomas Gleixner , kernel-team@lge.com, linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, oleg@redhat.com, tj@kernel.org Subject: [PATCH] locking/lockdep: Add CONFIG_LOCKDEP_AGGRESSIVE Date: Sun, 10 Dec 2017 22:50:17 -0500 Message-Id: <20171211035017.32678-1-tytso@mit.edu> X-Mailer: git-send-email 2.11.0.rc0.7.gbe5a750 X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-block-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-block@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS can result in a large number of false positives because lockdep doesn't understand how to deal with multiple stacked loop or MD devices. Until someone can figure out how to automatically add annotations to all file system and storage devices --- hopefully without forcing developers to insert a large number of calls to undocumented lockdep macros into the the loop device, every single file system, and every single device-mapper backend --- let's add an option to allow these lockdep features to be disabled. Otherwise, many file system developers will disable LOCKDEP entirely since it results in far too many false positives when trying to use xfstests. Signed-off-by: Theodore Ts'o Cc: Byungchul Park Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: kernel-team@lge.com Cc: linux-block@vger.kernel.org Cc: linux-fsdevel@vger.kernel.org Cc: oleg@redhat.com Cc: tj@kernel.org --- lib/Kconfig.debug | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 947d3e2ed5c2..acae7ba99c16 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -1099,8 +1099,8 @@ config PROVE_LOCKING select DEBUG_MUTEXES select DEBUG_RT_MUTEXES if RT_MUTEXES select DEBUG_LOCK_ALLOC - select LOCKDEP_CROSSRELEASE - select LOCKDEP_COMPLETIONS + select LOCKDEP_CROSSRELEASE if LOCKDEP_AGGRESSIVE + select LOCKDEP_COMPLETIONS if LOCKDEP_AGGRESSIVE select TRACE_IRQFLAGS default n help @@ -1137,6 +1137,16 @@ config PROVE_LOCKING For more details, see Documentation/locking/lockdep-design.txt. +config LOCKDEP_AGGRESSIVE + bool "Lock debugging: use aggressive techniques" + default n + help + This enables some extremely aggressive lockdep checking that + may result in false positives. + + Say N here if you are planning on using xfstests and don't + want to deal with many false positive test failures. + config LOCKDEP bool depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT