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]

Date:	Fri, 15 Jan 2016 00:01:44 +0000
From:	Mark Brown <broonie@...nel.org>
To:	Stefan Agner <stefan@...er.ch>
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 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.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)