From: "Vegard Nossum" <vegard.nossum@gmail.com>
To: linux-kernel@vger.kernel.org
Subject: Swap on loop device on tmpfs locks up machine
Date: Fri, 26 Sep 2008 20:46:20 +0200 [thread overview]
Message-ID: <19f34abd0809261146j72a68765i964466336a3a34dc@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3805 bytes --]
Hi,
It turns out that swap over loop device on tmpfs will lock up the
machine. That is, all programs become blocked, but I can still do
things like switch VT consoles.
To reproduce (as root):
mount -t tmpfs tmpfs /mnt
dd if=/dev/zero of=/mnt/disk
swapoff -a
losetup -f /mnt/disk
mkswap /dev/loop0 # replace loop0 with actual loop device
swapon /dev/loop0
<memory hog, like continuous malloc()>
I'm not sure it's really a very good idea to do this in the first
place, but should something give a warning or prevent a user from
doing it?
There is no output on serial console, I have most debugging options
turned on. SysRq-l (backtrace for active CPUs) shows nothing much
interesting:
Pid: 0, comm: swapper Not tainted (2.6.27-rc7-00106-g6ef190c #1)
EIP: 0060:[<c011f295>] EFLAGS: 00000202 CPU: 0
EIP is at native_safe_halt+0x5/0x10
And SysRq-w (task dump for blocked tasks) shows that almost all
processes are blocking in schedule_timeout, for example:
bash D f6eb5cf0 6184 3688 3687
f6eb5d38 00200046 00000000 f6eb5cf0 c0159b4f 00000000 f6a7f2c0 c0159d7b
c2036d80 f6933fc0 67525eae 000000f4 f6a7f2c0 f6a7f534 c2036d80 f6eb4000
c0595da3 c0955b80 000210af 00000000 c013f9eb 000124b0 00000000 00200296
Call Trace:
[<c0159b4f>] ? mark_held_locks+0x6f/0x90
[<c0159d7b>] ? trace_hardirqs_on+0xb/0x10
[<c0595da3>] ? _spin_unlock_irqrestore+0x43/0x70
[<c013f9eb>] ? __mod_timer+0x9b/0xe0
[<c05933c8>] schedule_timeout+0x48/0xc0
[<c0159d7b>] ? trace_hardirqs_on+0xb/0x10
[<c013f480>] ? process_timeout+0x0/0x10
[<c05933c3>] ? schedule_timeout+0x43/0xc0
[<c05932ee>] io_schedule_timeout+0x1e/0x30
[<c0187385>] congestion_wait+0x55/0x70
[<c0149900>] ? autoremove_wake_function+0x0/0x50
[<c0181969>] throttle_vm_writeout+0x69/0x80
[<c0184fa5>] shrink_zone+0x75/0x130
[<c010a325>] ? native_sched_clock+0xb5/0x110
[<c01853c7>] do_try_to_free_pages+0x107/0x3c0
[<c018576d>] try_to_free_pages+0x6d/0x80
[<c0183ea0>] ? isolate_pages_global+0x0/0x60
[<c017fef5>] __alloc_pages_internal+0x1a5/0x440
[<c018911d>] do_wp_page+0xad/0x550
[<c018a8e9>] handle_mm_fault+0x409/0x7b0
[<c014da1d>] ? down_read_trylock+0x5d/0x70
[<c0120808>] do_page_fault+0x298/0x700
[<c028cee8>] ? copy_to_user+0x48/0x60
[<c028c7e4>] ? trace_hardirqs_on_thunk+0xc/0x10
[<c0120570>] ? do_page_fault+0x0/0x700
[<c059615a>] error_code+0x72/0x78
The only process that isn't hung in schedule_timeout() is this:
loop0 D f6727dec 7128 3731 2
f6727e04 00000046 00000002 f6727dec f6727df4 00000000 00000001 00000303
c2161d80 f7856600 f6f6f2c0 c0700e0c f6f6f2c0 f6f6f534 c2161d80 f6726000
00001b23 ffffffff f7425180 f6727df0 00000000 00000000 00000000 0000007f
Call Trace:
[<c059331e>] io_schedule+0x1e/0x30
[<c0179ed7>] sync_page+0x37/0x50
[<c05935b5>] __wait_on_bit+0x45/0x70
[<c0179ea0>] ? sync_page+0x0/0x50
[<c017a125>] wait_on_page_bit+0x55/0x60
[<c0149950>] ? wake_bit_function+0x0/0x60
[<c019a788>] shmem_getpage+0x588/0x770
[<c0159d7b>] ? trace_hardirqs_on+0xb/0x10
[<c019a9aa>] shmem_write_begin+0x3a/0x50
[<c017a361>] pagecache_write_begin+0x51/0x130
[<c03135ec>] do_lo_send_aops+0xac/0x1b0
[<c0159ce4>] ? trace_hardirqs_on_caller+0xd4/0x160
[<c0313371>] loop_thread+0x301/0x410
[<c0313540>] ? do_lo_send_aops+0x0/0x1b0
[<c0149900>] ? autoremove_wake_function+0x0/0x50
[<c0313070>] ? loop_thread+0x0/0x410
[<c0149612>] kthread+0x42/0x70
[<c01495d0>] ? kthread+0x0/0x70
[<c0104e93>] kernel_thread_helper+0x7/0x14
The memory hog is also attached for reference.
Vegard
--
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
-- E. W. Dijkstra, EWD1036
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: swap.c --]
[-- Type: text/x-csrc; name=swap.c, Size: 106 bytes --]
#include <stdlib.h>
int main(void)
{
while (1) {
char *x = malloc(4095);
x[0] = 0;
}
return 0;
}
next reply other threads:[~2008-09-26 18:46 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-26 18:46 Vegard Nossum [this message]
2008-09-27 12:49 ` David Newall
2008-09-27 17:38 ` Bill Davidsen
2008-09-27 18:30 ` Vegard Nossum
2008-09-28 15:18 ` Hugh Dickins
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=19f34abd0809261146j72a68765i964466336a3a34dc@mail.gmail.com \
--to=vegard.nossum@gmail.com \
--cc=linux-kernel@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
all inboxes | Powered by JetHome®