From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S938062AbdEYM7Y (ORCPT ); Thu, 25 May 2017 08:59:24 -0400 Received: from omzsmtpe03.verizonbusiness.com ([199.249.25.208]:32014 "EHLO omzsmtpe03.verizonbusiness.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1765899AbdEYM7R (ORCPT ); Thu, 25 May 2017 08:59:17 -0400 X-IronPort-Anti-Spam-Filtered: false From: "Levin, Alexander (Sasha Levin)" X-IronPort-AV: E=Sophos;i="5.38,391,1491264000"; d="scan'208";a="358081848" To: "mingo@kernel.org" CC: "linux-kernel@vger.kernel.org" , "ben@decadent.org.uk" , "a.p.zijlstra@chello.nl" , "tglx@linutronix.de" Subject: [PATCH 02/21] liblockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain::depth Thread-Topic: [PATCH 02/21] liblockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain::depth Thread-Index: AQHS1Vad0DA/KTtllUeubf5mwSOIzQ== Date: Thu, 25 May 2017 12:58:33 +0000 Message-ID: <20170525130005.5947-3-alexander.levin@verizon.com> References: <20170525130005.5947-1-alexander.levin@verizon.com> In-Reply-To: <20170525130005.5947-1-alexander.levin@verizon.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.144.60.250] Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.home.local id v4PD3j4a004255 From: Ben Hutchings 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. Cc: # for versions before 4.6, use a value of 255 Signed-off-by: Ben Hutchings Signed-off-by: Sasha Levin --- 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 c808c7d02d21..d30214221920 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 -- 2.11.0