Messages in this thread |  | | | Date | Fri, 26 Sep 2008 20:46:20 +0200 | | From | "Vegard Nossum" <> | | Subject | Swap on loop device on tmpfs locks up machine |
| |
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 #include <stdlib.h>
int main(void) { while (1) { char *x = malloc(4095); x[0] = 0; } return 0; } |  |