From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751422AbdFEJGW (ORCPT ); Mon, 5 Jun 2017 05:06:22 -0400 Received: from terminus.zytor.com ([65.50.211.136]:38999 "EHLO terminus.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751272AbdFEJGU (ORCPT ); Mon, 5 Jun 2017 05:06:20 -0400 Date: Mon, 5 Jun 2017 02:01:45 -0700 From: tip-bot for Ben Hutchings Message-ID: Cc: ben@decadent.org.uk, mingo@kernel.org, tglx@linutronix.de, torvalds@linux-foundation.org, sasha.levin@oracle.com, linux-kernel@vger.kernel.org, hpa@zytor.com, peterz@infradead.org Reply-To: tglx@linutronix.de, mingo@kernel.org, ben@decadent.org.uk, hpa@zytor.com, peterz@infradead.org, torvalds@linux-foundation.org, linux-kernel@vger.kernel.org, sasha.levin@oracle.com In-Reply-To: <20170525130005.5947-3-alexander.levin@verizon.com> References: <20170525130005.5947-3-alexander.levin@verizon.com> To: linux-tip-commits@vger.kernel.org Subject: [tip:locking/core] tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth Git-Commit-ID: 98dcea0cfd04e083ac74137ceb9a632604740e2d X-Mailer: tip-git-log-daemon Robot-ID: Robot-Unsubscribe: Contact to get blacklisted from these emails MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Commit-ID: 98dcea0cfd04e083ac74137ceb9a632604740e2d Gitweb: http://git.kernel.org/tip/98dcea0cfd04e083ac74137ceb9a632604740e2d Author: Ben Hutchings AuthorDate: Thu, 25 May 2017 12:58:33 +0000 Committer: Ingo Molnar CommitDate: Mon, 5 Jun 2017 09:28:03 +0200 tools/lib/lockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain/: Depth liblockdep has been broken since commit 75dd602a5198 ("lockdep: Fix lock_chain::base size"), as that adds a check that MAX_LOCK_DEPTH is within the range of lock_chain::depth and in liblockdep it is much too large. That should have resulted in a compiler error, but didn't because: - the check uses ARRAY_SIZE(), which isn't yet defined in liblockdep so is assumed to be an (undeclared) function - putting a function call inside a BUILD_BUG_ON() expression quietly turns it into some nonsense involving a variable-length array It did produce a compiler warning, but I didn't notice because liblockdep already produces too many warnings if -Wall is enabled (which I'll fix shortly). Even before that commit, which reduced lock_chain::depth from 8 bits to 6, MAX_LOCK_DEPTH was too large. Signed-off-by: Ben Hutchings Signed-off-by: Sasha Levin Cc: # for versions before 4.6, use a value of 255 Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: a.p.zijlstra@chello.nl Link: http://lkml.kernel.org/r/20170525130005.5947-3-alexander.levin@verizon.com Signed-off-by: Ingo Molnar --- tools/lib/lockdep/uinclude/linux/lockdep.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/lib/lockdep/uinclude/linux/lockdep.h b/tools/lib/lockdep/uinclude/linux/lockdep.h index c808c7d..d302142 100644 --- a/tools/lib/lockdep/uinclude/linux/lockdep.h +++ b/tools/lib/lockdep/uinclude/linux/lockdep.h @@ -8,7 +8,7 @@ #include #include -#define MAX_LOCK_DEPTH 2000UL +#define MAX_LOCK_DEPTH 63UL #define asmlinkage #define __visible