From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752833AbbJNMgr (ORCPT ); Wed, 14 Oct 2015 08:36:47 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:58411 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751478AbbJNMgp (ORCPT ); Wed, 14 Oct 2015 08:36:45 -0400 Date: Wed, 14 Oct 2015 13:36:24 +0100 From: Mark Brown To: Peter Zijlstra Cc: Arnd Bergmann , Ingo Molnar , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, Liam Girdwood , akpm@linux-foundation.org, Sascha Hauer Message-ID: <20151014123624.GV14956@sirena.org.uk> References: <11282238.AHmyWliPRj@wuerfel> <20151013203812.GM17308@twins.programming.kicks-ass.net> <11817958.z9KtmeKzV7@wuerfel> <20151014082050.GQ17308@twins.programming.kicks-ass.net> <20151014102706.GR14956@sirena.org.uk> <20151014110717.GT17308@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aXNiKu4lnbRqA5kZ" Content-Disposition: inline In-Reply-To: <20151014110717.GT17308@twins.programming.kicks-ass.net> X-Cookie: Do you like "TENDER VITTLES"? User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: 94.175.94.161 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH] mutex: make mutex_lock_nested an inline function X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --aXNiKu4lnbRqA5kZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Oct 14, 2015 at 01:07:17PM +0200, Peter Zijlstra wrote: > On Wed, Oct 14, 2015 at 11:27:06AM +0100, Mark Brown wrote: > > On Wed, Oct 14, 2015 at 10:20:50AM +0200, Peter Zijlstra wrote: > > > Uuh, I just looked at next and saw this regulator_lock_supply() > > > function. How is that limited? subclass must be <8 otherwise bad thin= gs > > > happen. > > Can we please get some more discoverable documentation of the arbitrary > > limits in the lockdep code?=20 > include/linux/lockdep.h:#define MAX_LOCKDEP_SUBCLASSES 8UL Sure, but I don't really expect to have to trawl the implementation of an API to find out about this sort of thing (I hadn't even been aware that the subclasses were required to be small positive integers, never mind needing to check what the limit was). I think the main place I'd have expected to see it was in lockdep-design.txt or somewhere near that. > > I seem to keep seeing code that bumps into > > surprising limits like this and I'm not sure how I'm supposed to know > > about them except through finding out after the fact or trawling the > > code every time someone touches locking. > Not knowing what other limits you've hit, I'm not entirely sure how to > help out there. The other big one that came up recently was that lockdep apparently works out what a class is by looking at the point of allocation which causes a lot of problems for regmap since it makes all regmap locks look like a single class. That's fixed now by explicitly allocating a class per regmap with some macro magic but it was a bit of a surprise. The documentation doesn't make this obvious. --aXNiKu4lnbRqA5kZ Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWHkxHAAoJECTWi3JdVIfQ0MEH/R50AZlAkqsPOp4BXIQJAL75 o69adXDMx/4u6WF/oTCbi2aRlX5Nru3Px6enVdk+1cstwIaV85MIatuER3XAraPK HJYHABiHPHMs+f6u1lLA6JhxgQTzpdjd8/+2AB4AoVLsx/qDJ4NEQKqqf7s2s4Un iYSPGk4G0wXFFEfjzRrsMziau36V0c8Fkov/m3wc8oKW/aWqdHf+NgGOess/ERfg m1u+lUwEI4OWVE/izswhd84xWh/E5DXLNPaV/vCRvvJT3KZo/wPD+lAvs/8MibD4 2tyVKZ7gBCHTYIWDmLVHRrKSd3DP+tMkPlBZqvBGnE89nKQrDRXD9amJ28G9YFM= =mdEG -----END PGP SIGNATURE----- --aXNiKu4lnbRqA5kZ--