From: Joel Fernandes <joelaf@google.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Christoph Hellwig <hch@lst.de>,
Andrew Morton <akpm@linux-foundation.org>,
Jisheng Zhang <jszhang@marvell.com>,
John Dias <joaodias@google.com>,
"open list:MEMORY MANAGEMENT" <linux-mm@kvack.org>,
linux-rt-users@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/6] mm: mark all calls into the vmalloc subsystem as potentially sleeping
Date: Tue, 8 Nov 2016 05:24:30 -0800 [thread overview]
Message-ID: <CAJWu+opLAwJ+OsT6DRx1qNEph8YRc5nCWp8uputAGcgMGs0oPg@mail.gmail.com> (raw)
In-Reply-To: <20161019111541.GQ29358@nuc-i3427.alporthouse.com>
On Wed, Oct 19, 2016 at 4:15 AM, Chris Wilson <chris@chris-wilson.co.uk> wrote:
> 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
>From this traceback, it looks like the lock causing the atomic context
was actually acquired in the vfree path itself, and not by the vmapped
stack user (as it says "vmap_area_lock" held). I am still wondering
why vmap_area_lock was held during the might_sleep(), perhaps you may
not have applied all patches from Chris H?
>From the patches I saw, vmap_area_lock is not acquired during any of
the might_sleep Chris H added, but I may be missing something. In
anycase looks to me like the atomicity is introduced by the vfree path
itself and not the caller.
Thanks!
Joel
> [ 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
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
next prev parent reply other threads:[~2016-11-08 13:24 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
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 [this message]
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=CAJWu+opLAwJ+OsT6DRx1qNEph8YRc5nCWp8uputAGcgMGs0oPg@mail.gmail.com \
--to=joelaf@google.com \
--cc=akpm@linux-foundation.org \
--cc=chris@chris-wilson.co.uk \
--cc=hch@lst.de \
--cc=joaodias@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