From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754437AbcAOACN (ORCPT ); Thu, 14 Jan 2016 19:02:13 -0500 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:54793 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752162AbcAOACK (ORCPT ); Thu, 14 Jan 2016 19:02:10 -0500 Date: Fri, 15 Jan 2016 00:01:44 +0000 From: Mark Brown To: Stefan Agner Cc: festevam@gmail.com, peterz@infradead.org, mingo@redhat.com, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Message-ID: <20160115000144.GU6588@sirena.org.uk> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9uH70MWbZgudpa7t" Content-Disposition: inline In-Reply-To: X-Cookie: APL hackers do it in the quad. User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: 2a01:348:6:8808:fab::3 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: Lockdep warning when using REGCACHE_RBTREE 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 --9uH70MWbZgudpa7t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Jan 14, 2016 at 02:30:50PM -0800, Stefan Agner wrote: > I currently work on the DCU DRM driver (drivers/gpu/drm/fsl-dcu/) on a > Linux 4.4 kernel. With CONFIG_LOCKDEP enabled I get the following > warning on startup: Please don't paste entire stack dumps into e-mail, they're completely unedifying and obscure the actual content in your e-mail. Edit down relevant pieces of information. > [ 1.327284] ------------[ cut here ]------------ > [ 1.332010] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2755 > lockdep_trace_alloc+0x120/0x124() > [ 1.341358] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) > I do use REGCACHE_RBTREE along with regmap_write from within the probe > code path of the driver. This ultimately leads to an allocation. > However, what I don't understand is why the allocation is leading to > that error. The actual allocation happens in regcache_rbtree_node_alloc > and seems to be a rather common kzalloc with GFP_KERNEL... > The comment in __lockdep_trace_alloc says: > "Oi! Can't be having __GFP_FS allocations with IRQs disabled.". That appears to match with the warning printed. Either this is a false positive from lockdep or you are actually trying to cache a new register in atomic context which is not and has never been supported, are any of the functions in the backtrace taking relevant locks? > Not sure if this is a Linux 4.4 issue, Fabio Estevam reported a similar > issue just recently, not sure if that is related: > https://lkml.org/lkml/2016/1/11/284 Nothing has changed here in lockdep, doing allocations in atomic context has never been supported. --9uH70MWbZgudpa7t Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJWmDbnAAoJECTWi3JdVIfQ80AH/0+MD2kSLr4PwjqcV278fLgq aUOkT9+WlmbwlwZoU0o133q0GIhFAKojNaQ77QLmix+VFHiYKa/xJF3HWAsMV+GL X3Qd20ifEVIna8sQ10QPWEgl+TM5RISeSMlWaSKQGpruzCvDMq7xtNiRJdvph7D8 fbg9nRdz+9muorf33M+WcmXdIpE78IACHZCI6LC+5cMt3zis6QGZmfI/eUqZIoU9 O6w7FGC9lMkHxFpM7OAYAlcxy3VzQzbFL1mICcknV+1s8nm3vcLM9xiU2BqnzuYf l5E20RJq6eupsxR1X7aEaRFL2tqkfx69gds+xDhgp7DkfHlcx8ECQ3QPgcRIEuQ= =cBJp -----END PGP SIGNATURE----- --9uH70MWbZgudpa7t--