[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171030084225.n3e2lsrkmjdxh6gf@hirez.programming.kicks-ass.net>
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.
Powered by blists - more mailing lists