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.