linux-kernel - WARNING: possible circular locking dependency detected

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-next>] [day] [month] [year] [list]

Date:   Fri, 25 Aug 2017 12:03:04 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Peter Zijlstra <peterz@...radead.org>,
        lkml <linux-kernel@...r.kernel.org>
Subject: WARNING: possible circular locking dependency detected

Hey,

tglx says I have something for ya :-)

======================================================
WARNING: possible circular locking dependency detected
4.13.0-rc6+ #1 Not tainted
------------------------------------------------------
watchdog/3/27 is trying to acquire lock:
 (cpu_hotplug_lock.rw_sem){++++}, at: [<ffffffff8100c489>] release_ds_buffers+0x29/0xd0

but now in release context of a crosslock acquired at the following:
 ((complete)&self->parked){+.+.}, at: [<ffffffff810895f6>] kthread_park+0x46/0x60

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #2 ((complete)&self->parked){+.+.}:
       __lock_acquire+0x10af/0x1110
       lock_acquire+0xea/0x1f0
       wait_for_completion+0x3b/0x130
       kthread_park+0x46/0x60
       __smpboot_create_thread.part.5+0x7d/0xf0
       smpboot_register_percpu_thread_cpumask+0xa2/0x100
       spawn_ksoftirqd+0x3b/0x45
       do_one_initcall+0x52/0x198
       kernel_init_freeable+0x6f/0x1a1
       kernel_init+0xe/0x100
       ret_from_fork+0x2a/0x40

-> #1 (smpboot_threads_lock){+.+.}:
       __lock_acquire+0x10af/0x1110
       lock_acquire+0xea/0x1f0
       __mutex_lock+0x6c/0x940
       mutex_lock_nested+0x1b/0x20
       smpboot_register_percpu_thread_cpumask+0x42/0x100
       spawn_ksoftirqd+0x3b/0x45
       do_one_initcall+0x52/0x198
       kernel_init_freeable+0x6f/0x1a1
       kernel_init+0xe/0x100
       ret_from_fork+0x2a/0x40

-> #0 (cpu_hotplug_lock.rw_sem){++++}:
       cpus_read_lock+0x2a/0x90
       release_ds_buffers+0x29/0xd0
       x86_release_hardware+0x8f/0xa0
       hw_perf_event_destroy+0xe/0x20
       _free_event+0xa7/0x250

other info that might help us debug this:

Chain exists of:
  cpu_hotplug_lock.rw_sem --> smpboot_threads_lock --> (complete)&self->parked

 Possible unsafe locking scenario by crosslock:

       CPU0                    CPU1
       ----                    ----
  lock(smpboot_threads_lock);
  lock((complete)&self->parked);
                               lock(cpu_hotplug_lock.rw_sem);
                               unlock((complete)&self->parked);

 *** DEADLOCK ***

1 lock held by watchdog/3/27:
 #0:  (&x->wait){....}, at: [<ffffffff810b115d>] complete+0x1d/0x60

stack backtrace:
CPU: 3 PID: 27 Comm: watchdog/3 Not tainted 4.13.0-rc6+ #1
Hardware name: LENOVO 2320CTO/2320CTO, BIOS G2ET86WW (2.06 ) 11/13/2012
Call Trace:
 dump_stack+0x86/0xcf
 print_circular_bug+0x1fa/0x2f0
 check_prev_add+0x3be/0x700
 ? __lock_acquire+0x4c6/0x1110
 ? trace_event_raw_event_lock+0xf0/0xf0
 lock_commit_crosslock+0x40d/0x590
 ? lock_commit_crosslock+0x40d/0x590
 complete+0x29/0x60
 __kthread_parkme+0x54/0x80
 kthread_parkme+0x24/0x40
 smpboot_thread_fn+0x95/0x230
 kthread+0x147/0x180
 ? sort_range+0x30/0x30
 ? kthread_create_on_node+0x40/0x40
 ret_from_fork+0x2a/0x40


-- 
Regards/Gruss,
    Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.