linux-kernel - Re: [driver core] e3b1cb5c89: WARNING:possible_recursive_locking

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:   Sat, 25 Jul 2020 13:07:33 +0200
From:   Lukas Wunner <lukas@...ner.de>
To:     kernel test robot <rong.a.chen@...el.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        "Rafael J. Wysocki" <rafael@...nel.org>,
        Dan Williams <dan.j.williams@...el.com>,
        Geert Uytterhoeven <geert+renesas@...der.be>,
        Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
        Alexander Duyck <alexander.h.duyck@...ux.intel.com>,
        Mark Brown <broonie@...nel.org>, linux-kernel@...r.kernel.org,
        linux-spi@...r.kernel.org, 0day robot <lkp@...el.com>,
        lkp@...ts.01.org
Subject: Re: [driver core] e3b1cb5c89:
 WARNING:possible_recursive_locking_detected

On Fri, Jul 24, 2020 at 10:29:50PM +0800, kernel test robot wrote:
> commit: e3b1cb5c896ba748d8f848238c8ea1f89520bde3 ("[PATCH 3/3] driver core: Avoid adding children below a dead parent")
[...]
> [    1.392584] WARNING: possible recursive locking detected
> [    1.393350] 5.8.0-rc3-00011-ge3b1cb5c896ba7 #1 Not tainted
> [    1.393350] --------------------------------------------
> [    1.393350] swapper/0/1 is trying to acquire lock:
> [    1.393350] ffff88841fc6ff70 (&dev->p->dead_sem){.+.+}-{3:3}, at: __device_attach+0x51/0x1a0
> [    1.393350] 
> [    1.393350] but task is already holding lock:
> [    1.393350] ffff888107f42770 (&dev->p->dead_sem){.+.+}-{3:3}, at: device_add+0xf8/0x890

False positive:

__device_attach() takes a device's dead_sem whereas device_add() takes
the *parent's* dead_sem.  But lockdep thinks they're the same because
they're in the same lock class.

We would normally see the same lockdep splat for device_lock() but
commit 1704f47b50b5 silenced it by assigning device_lock() to the
novalidate class.

I could silence this lockdep splat by assigning dead_sem to the
novalidate class as well.  But I also have an idea how we could
fix it properly by introducing a per-device class for bus_types
that need it and by putting the device_lock, dead_sem etc in
separate subclasses within that per-device class.

Any preference as to which solution I should pursue?
Any thoughts on this series in general?
Does the newly introduced dead_sem evoke approval or rejection?
Anyone?

Thanks,

Lukas