From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753079AbcFNVNm (ORCPT ); Tue, 14 Jun 2016 17:13:42 -0400 Received: from merlin.infradead.org ([205.233.59.134]:36876 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752800AbcFNVNl (ORCPT ); Tue, 14 Jun 2016 17:13:41 -0400 Date: Tue, 14 Jun 2016 23:13:32 +0200 From: Peter Zijlstra To: Ben Hutchings Cc: Sasha Levin , linux-kernel@vger.kernel.org, stable@vger.kernel.org, Ingo Molnar Subject: Re: [PATCH 2/7] liblockdep: Reduce MAX_LOCK_DEPTH to avoid overflowing lock_chain::depth Message-ID: <20160614211332.GJ30154@twins.programming.kicks-ass.net> References: <20160614204437.GS7555@decadent.org.uk> <20160614204752.GU7555@decadent.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160614204752.GU7555@decadent.org.uk> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 14, 2016 at 09:47:53PM +0100, Ben Hutchings wrote: > Even before that commit, which reduced lock_chain::depth from 8 bits > to 6, MAX_LOCK_DEPTH was too large. > -#define MAX_LOCK_DEPTH 2000UL > +#define MAX_LOCK_DEPTH 63UL So per that commit; there still is a 4 byte hole we could fill. So if a bigger number is desired here, there is room to make that happen. Good to see those assertions did their job, albeit somewhat belated.