From: Chris Wilson <chris@chris-wilson.co.uk>
To: Christoph Hellwig <hch@lst.de>
Cc: akpm@linux-foundation.org, joelaf@google.com,
jszhang@marvell.com, joaodias@google.com, linux-mm@kvack.org,
linux-rt-users@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping
Date: Wed, 19 Oct 2016 12:15:41 +0100 [thread overview]
Message-ID: <20161019111541.GQ29358@nuc-i3427.alporthouse.com> (raw)
In-Reply-To: <1476773771-11470-3-git-send-email-hch@lst.de>
On Tue, Oct 18, 2016 at 08:56:07AM +0200, Christoph Hellwig wrote:
> This is how everyone seems to already use them, but let's make that
> explicit.
Ah, found an exception, vmapped stacks:
[ 696.928541] BUG: sleeping function called from invalid context at mm/vmalloc.c:615
[ 696.928576] in_atomic(): 1, irqs_disabled(): 0, pid: 30521, name: bash
[ 696.928590] 1 lock held by bash/30521:
[ 696.928600] #0: [ 696.928606] (vmap_area_lock[ 696.928619] ){+.+...}, at: [ 696.928640] [<ffffffff8115f0cf>] __purge_vmap_area_lazy+0x30f/0x370
[ 696.928656] CPU: 0 PID: 30521 Comm: bash Tainted: G W 4.9.0-rc1+ #124
[ 696.928672] Hardware name: / , BIOS PYBSWCEL.86A.0027.2015.0507.1758 05/07/2015
[ 696.928690] ffffc900070f7c70 ffffffff812be1f5 ffff8802750b6680 ffffffff819650a6
[ 696.928717] ffffc900070f7c98 ffffffff810a3216 0000000000004001 ffff8802726e16c0
[ 696.928743] ffff8802726e19a0 ffffc900070f7d08 ffffffff8115f0f3 ffff8802750b6680
[ 696.928768] Call Trace:
[ 696.928782] [<ffffffff812be1f5>] dump_stack+0x68/0x93
[ 696.928796] [<ffffffff810a3216>] ___might_sleep+0x166/0x220
[ 696.928809] [<ffffffff8115f0f3>] __purge_vmap_area_lazy+0x333/0x370
[ 696.928823] [<ffffffff8115ea68>] ? vunmap_page_range+0x1e8/0x350
[ 696.928837] [<ffffffff8115f1b3>] free_vmap_area_noflush+0x83/0x90
[ 696.928850] [<ffffffff81160931>] remove_vm_area+0x71/0xb0
[ 696.928863] [<ffffffff81160999>] __vunmap+0x29/0xf0
[ 696.928875] [<ffffffff81160ab9>] vfree+0x29/0x70
[ 696.928888] [<ffffffff81071746>] put_task_stack+0x76/0x120
[ 696.928901] [<ffffffff8109a943>] finish_task_switch+0x163/0x1e0
[ 696.928914] [<ffffffff8109a845>] ? finish_task_switch+0x65/0x1e0
[ 696.928928] [<ffffffff816125f5>] __schedule+0x1f5/0x7c0
[ 696.928940] [<ffffffff81612c28>] schedule+0x38/0x90
[ 696.928953] [<ffffffff810787b1>] do_wait+0x1d1/0x200
[ 696.928966] [<ffffffff810799b1>] SyS_wait4+0x61/0xc0
[ 696.928979] [<ffffffff81076e50>] ? task_stopped_code+0x50/0x50
[ 696.928992] [<ffffffff81618e6e>] entry_SYSCALL_64_fastpath+0x1c/0xb1
[This was triggered by earlier patch to remove the serialisation and add
cond_resched_lock(&vmap_area_lock)]
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
next prev parent reply other threads:[~2016-10-19 14:32 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-10-18 6:56 [RFC] reduce latency in __purge_vmap_area_lazy Christoph Hellwig
2016-10-18 6:56 ` [PATCH 1/6] mm: refactor __purge_vmap_area_lazy Christoph Hellwig
2016-10-18 6:56 ` [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping Christoph Hellwig
2016-10-18 10:33 ` Chris Wilson
2016-10-18 10:38 ` Christoph Hellwig
2016-10-19 11:15 ` Chris Wilson [this message]
2016-10-19 13:05 ` Christoph Hellwig
2016-10-19 15:34 ` Andy Lutomirski
2016-10-19 16:31 ` Christoph Hellwig
2016-10-19 19:43 ` Chris Wilson
2016-10-21 0:32 ` Joel Fernandes
2016-11-08 13:24 ` Joel Fernandes
2016-11-08 14:32 ` Andrey Ryabinin
2016-10-18 6:56 ` [PATCH 3/6] mm: remove free_unmap_vmap_area_noflush Christoph Hellwig
2016-10-18 6:56 ` [PATCH 4/6] mm: remove free_unmap_vmap_area_addr Christoph Hellwig
2016-10-21 0:46 ` Joel Fernandes
2016-10-21 1:58 ` Nicholas Piggin
2016-10-18 6:56 ` [PATCH 5/6] mm: turn vmap_purge_lock into a mutex Christoph Hellwig
2016-10-18 6:56 ` [PATCH 6/6] mm: add preempt points into __purge_vmap_area_lazy Christoph Hellwig
2016-10-18 20:56 ` Steven Rostedt
2016-10-18 21:01 ` Steven Rostedt
2016-10-18 10:40 ` [RFC] reduce latency in __purge_vmap_area_lazy Nicholas Piggin
2016-10-18 11:21 ` Jisheng Zhang
2016-10-21 1:08 ` Joel Fernandes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161019111541.GQ29358@nuc-i3427.alporthouse.com \
--to=chris@chris-wilson.co.uk \
--cc=akpm@linux-foundation.org \
--cc=hch@lst.de \
--cc=joaodias@google.com \
--cc=joelaf@google.com \
--cc=jszhang@marvell.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-rt-users@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).