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.