From: Vlastimil Babka <vbabka@suse.cz>
To: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: BUG: stuck on mmap_sem in 3.18.6
Date: Mon, 09 Feb 2015 11:34:32 +0100 [thread overview]
Message-ID: <54D88D38.9010901@suse.cz> (raw)
In-Reply-To: <CALYGNiOgSVgq+iaUs-f9MB4o8yOWb7jk6eEA=SMrqJh5K=6+hQ@mail.gmail.com>
On 02/09/2015 10:46 AM, Konstantin Khlebnikov wrote:
> On Mon, Feb 9, 2015 at 12:36 PM, Vlastimil Babka <vbabka@suse.cz> wrote:
>> On 02/09/2015 08:14 AM, Konstantin Khlebnikov wrote:
>>> Python was running under ptrace-based sandbox "sydbox" used exherbo
>>> chroot. Kernel: 3.18.6 + my patch "mm: prevent endless growth of
>>> anon_vma hierarchy" (patch seems stable).
>>>
>>> [ 4674.087780] INFO: task python:25873 blocked for more than 120 seconds.
>>> [ 4674.087793] Tainted: G U 3.18.6-zurg+ #158
>>> [ 4674.087797] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>>> disables this message.
>>> [ 4674.087801] python D ffff88041e2d2000 14176 25873 25630 0x00000102
>>> [ 4674.087817] ffff880286247b68 0000000000000086 ffff8803d5fe6b40
>>> 0000000000012000
>>> [ 4674.087824] ffff880286247fd8 0000000000012000 ffff88040c16eb40
>>> ffff8803d5fe6b40
>>> [ 4674.087830] 0000000300000003 ffff8803d5fe6b40 ffff880362888e78
>>> ffff880362888e60
>>> [ 4674.087836] Call Trace:
>>> [ 4674.087854] [<ffffffff81696be9>] schedule+0x29/0x70
>>> [ 4674.087865] [<ffffffff81699815>] rwsem_down_write_failed+0x1d5/0x2f0
>>> [ 4674.087873] [<ffffffff812d4c73>] call_rwsem_down_write_failed+0x13/0x20
>>> [ 4674.087881] [<ffffffff816990c1>] ? down_write+0x31/0x50
>>> [ 4674.087891] [<ffffffff811f3b44>] do_coredump+0x144/0xee0
>>> [ 4674.087900] [<ffffffff810b66f7>] ? pick_next_task_fair+0x397/0x450
>>> [ 4674.087909] [<ffffffff810026a6>] ? __switch_to+0x1d6/0x5f0
>>> [ 4674.087915] [<ffffffff816966e6>] ? __schedule+0x3a6/0x880
>>> [ 4674.087924] [<ffffffff81690000>] ? klist_remove+0x40/0xd0
>>> [ 4674.087932] [<ffffffff81093988>] get_signal+0x298/0x6b0
>>> [ 4674.087940] [<ffffffff81003588>] do_signal+0x28/0xbb0
>>> [ 4674.087946] [<ffffffff8109276d>] ? do_send_sig_info+0x5d/0x80
>>> [ 4674.087955] [<ffffffff81004179>] do_notify_resume+0x69/0xb0
>>> [ 4674.087963] [<ffffffff8169b028>] int_signal+0x12/0x17
>>>
>>> Maybe this guy did something wrong?
>>
>> Well he has do_coredump on stack, so he did something wrong in userspace? But
>> here he's just waiting on down_write. Unless there's some bug in do_coredump
>> that would lock for read and then for write, without an unlock in between?
>
> I mean khugepaged. This code looks really messy. Maybe it already has
> mmap_sem locked for read and tries to lock it again:
Yeah it is messy, and incidentally I'm trying to change how it works. But I
didn't find such double lock bug there.
--
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>
WARNING: multiple messages have this Message-ID (diff)
From: Vlastimil Babka <vbabka@suse.cz>
To: Konstantin Khlebnikov <koct9i@gmail.com>
Cc: "linux-mm@kvack.org" <linux-mm@kvack.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: BUG: stuck on mmap_sem in 3.18.6
Date: Mon, 09 Feb 2015 11:34:32 +0100 [thread overview]
Message-ID: <54D88D38.9010901@suse.cz> (raw)
In-Reply-To: <CALYGNiOgSVgq+iaUs-f9MB4o8yOWb7jk6eEA=SMrqJh5K=6+hQ@mail.gmail.com>
On 02/09/2015 10:46 AM, Konstantin Khlebnikov wrote:
> On Mon, Feb 9, 2015 at 12:36 PM, Vlastimil Babka <vbabka@suse.cz> wrote:
>> On 02/09/2015 08:14 AM, Konstantin Khlebnikov wrote:
>>> Python was running under ptrace-based sandbox "sydbox" used exherbo
>>> chroot. Kernel: 3.18.6 + my patch "mm: prevent endless growth of
>>> anon_vma hierarchy" (patch seems stable).
>>>
>>> [ 4674.087780] INFO: task python:25873 blocked for more than 120 seconds.
>>> [ 4674.087793] Tainted: G U 3.18.6-zurg+ #158
>>> [ 4674.087797] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs"
>>> disables this message.
>>> [ 4674.087801] python D ffff88041e2d2000 14176 25873 25630 0x00000102
>>> [ 4674.087817] ffff880286247b68 0000000000000086 ffff8803d5fe6b40
>>> 0000000000012000
>>> [ 4674.087824] ffff880286247fd8 0000000000012000 ffff88040c16eb40
>>> ffff8803d5fe6b40
>>> [ 4674.087830] 0000000300000003 ffff8803d5fe6b40 ffff880362888e78
>>> ffff880362888e60
>>> [ 4674.087836] Call Trace:
>>> [ 4674.087854] [<ffffffff81696be9>] schedule+0x29/0x70
>>> [ 4674.087865] [<ffffffff81699815>] rwsem_down_write_failed+0x1d5/0x2f0
>>> [ 4674.087873] [<ffffffff812d4c73>] call_rwsem_down_write_failed+0x13/0x20
>>> [ 4674.087881] [<ffffffff816990c1>] ? down_write+0x31/0x50
>>> [ 4674.087891] [<ffffffff811f3b44>] do_coredump+0x144/0xee0
>>> [ 4674.087900] [<ffffffff810b66f7>] ? pick_next_task_fair+0x397/0x450
>>> [ 4674.087909] [<ffffffff810026a6>] ? __switch_to+0x1d6/0x5f0
>>> [ 4674.087915] [<ffffffff816966e6>] ? __schedule+0x3a6/0x880
>>> [ 4674.087924] [<ffffffff81690000>] ? klist_remove+0x40/0xd0
>>> [ 4674.087932] [<ffffffff81093988>] get_signal+0x298/0x6b0
>>> [ 4674.087940] [<ffffffff81003588>] do_signal+0x28/0xbb0
>>> [ 4674.087946] [<ffffffff8109276d>] ? do_send_sig_info+0x5d/0x80
>>> [ 4674.087955] [<ffffffff81004179>] do_notify_resume+0x69/0xb0
>>> [ 4674.087963] [<ffffffff8169b028>] int_signal+0x12/0x17
>>>
>>> Maybe this guy did something wrong?
>>
>> Well he has do_coredump on stack, so he did something wrong in userspace? But
>> here he's just waiting on down_write. Unless there's some bug in do_coredump
>> that would lock for read and then for write, without an unlock in between?
>
> I mean khugepaged. This code looks really messy. Maybe it already has
> mmap_sem locked for read and tries to lock it again:
Yeah it is messy, and incidentally I'm trying to change how it works. But I
didn't find such double lock bug there.
next prev parent reply other threads:[~2015-02-09 10:34 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-09 7:14 BUG: stuck on mmap_sem in 3.18.6 Konstantin Khlebnikov
2015-02-09 7:14 ` Konstantin Khlebnikov
2015-02-09 9:36 ` Vlastimil Babka
2015-02-09 9:36 ` Vlastimil Babka
2015-02-09 9:46 ` Konstantin Khlebnikov
2015-02-09 9:46 ` Konstantin Khlebnikov
2015-02-09 10:34 ` Vlastimil Babka [this message]
2015-02-09 10:34 ` Vlastimil Babka
2015-02-10 8:26 ` Konstantin Khlebnikov
2015-02-10 8:26 ` Konstantin Khlebnikov
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=54D88D38.9010901@suse.cz \
--to=vbabka@suse.cz \
--cc=koct9i@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.