linux-kernel - Re: [perf_event_ctx_lock_nested] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97

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:   Mon, 30 Oct 2017 09:42:25 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Fengguang Wu <fengguang.wu@...el.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>
Subject: Re: [perf_event_ctx_lock_nested] BUG: sleeping function called from
 invalid context at kernel/locking/mutex.c:97

On Mon, Oct 30, 2017 at 12:02:01AM +0100, Fengguang Wu wrote:
> The dmesg fragment is
> 
> [   40.886662] done
> [   40.886686] [   40.905102] capability: warning: `turbostat' uses 32-bit
> capabilities (legacy support in use)
> [   40.940087] IPMI Device Information
> [   41.073351] [   41.076223] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97
> [   41.076224] in_atomic(): 1, irqs_disabled(): 0, pid: 14, name: watchdog/0
> [   41.076226] CPU: 0 PID: 14 Comm: watchdog/0 Tainted: G           O    4.8.0-01558-g21f54dd #1
                                                                           ^^^^^^^^^^^^^^^^^^^^

That's not 4.14 or even close.

> [   41.076228] Hardware name: Dell Inc. PowerEdge R630/0CNCJW, BIOS 2.1.7 06/16/2016
> [   41.076231]  ffffc900001bfd90 ffffffff813de3b9 ffff882062ab4b80 0000000000000061
> [   41.076232]  ffffc900001bfda8 ffffffff810a7083 ffffffff81c6fa60 ffffc900001bfdd0
> [   41.076233]  ffffffff810a711a ffff88206661d4a8 ffff882066037800 ffff88206661d4a8
> [   41.076234] Call Trace:
> [   41.076240]  [<ffffffff813de3b9>] dump_stack+0x63/0x8a
> [   41.076246]  [<ffffffff810a7083>] ___might_sleep+0xd3/0x120
> [   41.076248]  [<ffffffff810a711a>] __might_sleep+0x4a/0x80
> [   41.076254]  [<ffffffff818c5550>] mutex_lock+0x20/0x50
> [   41.076256]  [<ffffffff81179882>] perf_event_ctx_lock_nested+0x52/0xa0
> [   41.076259]  [<ffffffff8117ca1f>] perf_event_disable+0xf/0x30
> [   41.076261]  [<ffffffff81132056>] watchdog_nmi_disable+0x36/0x70
> [   41.076263]  [<ffffffff810a3a24>] ? smpboot_thread_fn+0x34/0x1f0
> [   41.076264]  [<ffffffff811320dd>] watchdog_disable+0x4d/0x60
> [   41.076266]  [<ffffffff810a3b53>] smpboot_thread_fn+0x163/0x1f0
> [   41.076267]  [<ffffffff810a39f0>] ? sort_range+0x30/0x30
> [   41.076269]  [<ffffffff810a05f5>] kthread+0xd5/0xf0
> [   41.076270]  [<ffffffff810a0520>] ? kthread_park+0x60/0x60
> [   41.076272]  [<ffffffff818c8345>] ret_from_fork+0x25/0x30

I'm not seeing where preemption would be disabled there.. we explicitly
call ->park() with preempt enabled.