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: <20160115094541.GH3421@worktop>
Date:	Fri, 15 Jan 2016 10:45:41 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Stefan Agner <stefan@...er.ch>
Cc:	broonie@...nel.org, festevam@...il.com, mingo@...hat.com,
	linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org
Subject: Re: Lockdep warning when using REGCACHE_RBTREE

On Thu, Jan 14, 2016 at 02:30:50PM -0800, Stefan Agner wrote:
> Hi Mark,
> 
> 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:
> 
> [    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))

> [    1.521744] [<80375308>] (_regmap_write) from [<80376760>] (regmap_write+0x48/0x68)
> [    1.535348] [<80376718>] (regmap_write) from [<803538e8>] (fsl_dcu_drm_crtc_create+0x98/0xe8)
> [    1.549824] [<80353850>] (fsl_dcu_drm_crtc_create) from [<80352df0>] (fsl_dcu_drm_modeset_init+0x5c/0xfc)


> The comment in __lockdep_trace_alloc says:
> "Oi! Can't be having __GFP_FS allocations with IRQs disabled.".

So _regmap_write() does: map->lock(map->lock_arg)

Which isn't very enlightening, since that can be a mutex or a spinlock,
the above strongly suggests spinlock though.

Looking at __regmap_init(), this seems to depend on:

  (bus && bus->fast_io) || config->fast_io

now, afaict, regmap_mmio is used in this case, which has .fast_io =
true.

So yeah, fail.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ