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.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
