linux-kernel - Re: Lockdep warning when using REGCACHE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <44832539ca2bcc0be6e08260083363fe@agner.ch>
Date:	Thu, 14 Jan 2016 17:14:47 -0800
From:	Stefan Agner <stefan@...er.ch>
To:	Mark Brown <broonie@...nel.org>
Cc:	festevam@...il.com, peterz@...radead.org, mingo@...hat.com,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: Lockdep warning when using REGCACHE_RBTREE

On 2016-01-14 16:01, Mark Brown wrote:
> 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?

Hm, I see. in_atomic at least doesn't report that I am in a atomic
context. None of the functions in the DCU driver use a spinlock
directly, I also checked some of the DRM core functions, there is the
drm_global_mutex, but not a spinlock.

When calling debug_check_no_locks_held() just before regmap_write I get
this:

[    1.441918]
[    1.443479] =====================================
[    1.448268] [ BUG: swapper/1 still has locks held! ]
[    1.453465] 4.4.0-00013-g7e569bc-dirty #59 Not tainted
[    1.458695] -------------------------------------
[    1.463598] 3 locks held by swapper/1:
[    1.467430]  #0:  (&dev->mutex){......}, at: [<80372f40>]
__driver_attach+0x50/0xa0
[    1.475446]  #1:  (&dev->mutex){......}, at: [<80372f50>]
__driver_attach+0x60/0xa0
[    1.483419]  #2:  (drm_global_mutex){+.+.+.}, at: [<80344bb0>]
drm_dev_register+0x24/0xc4
[    1.491924]

On a slightly other topic, I question whether REGCACHE_RBTREE is the
right cache type for the DCU DRM driver. The driver has uses a regmap
area of 1144 32-bit registers, the most space is used by the layer
configuration registers which are 0x40 apart and 0x0-0x20 for each layer
are actually used (hence somewhat above 50%).

Would FLAT be the better cache type?

--
Stefan

> 
>> 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.