Redhat kernel dump 분석 – 미르
Kernel Crash Dump Analysis Guide
소개
Tools
Crash 소개
기본명령어
사용방법
실행화면
Coredump Analysis 1
상황
분석과정
Coredump Analysis 2
상황
분석과정
Coredump Analysis 3
상황
분석과정
Coredump Analysis 4
상황
분석과정
Coredump Analysis 5
상황
분석과정
Coredump Analysis 6
상황
분석과정
Coredump Analysis 7
상황
분석과정
Coredump Analysis 8
상황
분석과정
Coredump Analysis 9
상황
분석과정
Kernel Crash Dump Analysis Guide#
소개#
커널 크래쉬(패닉) 혹은 Hangup 상태에서의 매직키 ( sysrq + m, t ) 등을 통한 코어덤프 생성후,
그 덤프파일을 분석하는 과정을 설명하는 문서이다.
Document Ver. – 2.1
Version History : 2009/5/5 – 1.0, 2009/12/16 – 2.0,2010/03/04 – 2.1
Written by Mirr at LDS ( Linuxdata system.co.ltd )
Test Enviroment – RedHat Enterprise Linux 계열
Tools#
필요한 툴 : crash ( crash 패키지 ), kernel-debug 패키지, kernel-devel 혹은 kernel-source 패키지. (코드분석을 위함)
햄버거 + 콜라 혹은 감자칩 + Beer.
Crash 소개#
커널 디버깅을 쉽게 할 수 있도록 제작된 레드햇에서 제공하는 툴.
기본명령어#
sys – 시스템의 일반적인 정보를 출력해 준다.
bt – Backtrace 명령. 스택의 내용들을 순차적으로 출력해준다.
ps – Process list 출력.
free – Memory 및 스왑 상태 출력.
mount – 마운트 상태 출력
irq – 각 장치의 ( irq ) 상태를 출력.
kmem – 메모리 상태 출력 ( kmalloc, valloc 등 메모리 할당 상태도 보여줌 )
log – dmesg 의 내용을 출력.
mod – 로딩된 모듈 리스트 출력.
net – Network 상태 출력.
runq – 실행중인 task 리스트 출력.
task – 작업목록 출력.
rd – 메모리 번지수에 대한 상세정보 출력.
foreach – 모든 task, process 등 디버깅 정보에 대한 상세한 출력이 가능함.
set – 설정된 주소 및 PID 등을 기본 컨텍스트로 설정.
struct – 구조화된 메모리 내부의 변수들을 출력해 준다.
files – task 가 열고있는 파일디스크립터들을 출력해준다.
사용방법#
Usage: crash {namelist} {dumpfile}
[root@Test DUMP]# crash vmlinux vmcore
Crash 로 코어덤프를 분석하기 위해선 Debug 모드가 활성화 된 상태의 커널이 필요하다. ( kernel-debug )
실제론 동일 버젼의 커널 디버그패키지의 vmlinuz 를 합축해제한 vmlinux 파일을 필요로 한다.
debug 커널의 vmlinux 추출 방법은 다음과 같다.
[root@Test DUMP]# rpm2cpio kernel-debug-{version}.rpm | cpio -idh
[root@Test DUMP]# cd boot && od -A d -t x1 vmlinuz | grep ‘1f 8b 08 00’
0019296 40 db 20 00 18 00 00 00 42 e1 0f 00 1f 8b 08 00
[root@Test boot]# dd if=vmlinuz bs=1 skip=19308 | zcat > vmlinux
간단히 설명하자면 rpm2cpio 로 rpm 의 내용을 추출 후,
vmlinuz 파일을 dd 명령으로 압축 해제 하는 것이다.
od 명령은 octaldump 로 file 을 특정 진법으로 덤프시켜주는 툴인데,
이것을 통해 압축코드 (1f 8b 08 00) 가 시작되는 주소를 찾아내어
압축되지 않은 vmlinux 를 추출하기 위한 작업이며, dd 명령을 통해 압축코드시작주소 ((0019296 + 12 ) 부터
덤프를 뜬뒤, zcat 으로 추출하는 과정이다. ( 역시 풀어설명하는게 더 복잡하다 그냥 명령어 코드 보자 )
실행화면#
[root@Test boot]$ crash vmlinux vmcore
crash 4.0-7
Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006 IBM Corporation
Copyright (C) 1999-2006 Hewlett-Packard Co
Copyright (C) 2005, 2006 Fujitsu Limited
Copyright (C) 2006, 2007 VA Linux Systems Japan K.K.
Copyright (C) 2005 NEC Corporation
Copyright (C) 1999, 2002, 2007 Silicon Graphics, Inc.
Copyright (C) 1999, 2000, 2001, 2002 Mission Critical Linux, Inc.
This program is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. Enter “help copying” to see the conditions.
This program has absolutely no warranty. Enter “help warranty” for details.
GNU gdb 6.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “i686-pc-linux-gnu”…
WARNING: kernels compiled by different gcc versions:
vmlinux: 3.4.6
vmcore kernel: 3.4.4
KERNEL: vmlinux
DUMPFILE: vmcore
CPUS: 4
DATE: Sun Apr 19 00:01:01 2009
UPTIME: 171 days, 10:40:23
LOAD AVERAGE: 0.07, 0.15, 0.11
TASKS: 252
NODENAME: node1
RELEASE: 2.6.9-22.ELsmp
VERSION: #1 SMP Mon Sep 19 18:32:14 EDT 2005
MACHINE: i686 (3392 Mhz)
MEMORY: 12.5 GB
PANIC: “kernel BUG at include/asm/spinlock.h:146!”
PID: 12339
COMMAND: “run-parts”
TASK: f3f02c30 [THREAD_INFO: cd001000]
CPU: 0
STATE: TASK_RUNNING (PANIC)
crash>
Coredump Analysis 1#
실제 코어분석중 주로 사용하게 되는 명령어들과 그것들에 대한 실제 사용법을 Case 별로 보여준다.
상황#
커널 패닉 혹은 Hangup 이 잦은 서버로써, 대부분의 스펙은 동일한 서버이나,
지역적으로 서로 떨어져 있으며, 산발적으로 일어나는 현상이라며 고객이 징징대고 있는 상황이다….. ㅜ.,ㅜ
OS : RedHat Enterprise Linux 4 Update 2 ( Kernel Ver. 2.6.9-22.ELsmp )
분석과정#
KERNEL: vmlinux
DUMPFILE: vmcore
CPUS: 4
DATE: Sun Apr 19 00:01:01 2009
UPTIME: 171 days, 10:40:23
LOAD AVERAGE: 0.07, 0.15, 0.11
TASKS: 252
NODENAME: node1
RELEASE: 2.6.9-22.ELsmp
VERSION: #1 SMP Mon Sep 19 18:32:14 EDT 2005
MACHINE: i686 (3392 Mhz)
MEMORY: 12.5 GB
PANIC: “kernel BUG at include/asm/spinlock.h:146!”
PID: 12339
COMMAND: “run-parts”
TASK: f3f02c30 [THREAD_INFO: cd001000]
CPU: 0
STATE: TASK_RUNNING (PANIC)
crash> bt -t
PID: 12339 TASK: f3f02c30 CPU: 0 COMMAND: “run-parts”
bt: cannot resolve stack trace:
#0 [cd001ddc] netpoll_start_netdump at f8d97570
#1 [cd001dfc] die at c0106015
#2 [cd001e30] do_invalid_op at c01063f0
#3 [cd001ee0] irq_entries_start at c02d1ba9
#4 [cd001fa8] do_group_exit at c0124482
bt: text symbols on stack:
[cd001df4] try_crashdump at c013403d
[cd001dfc] die at c010601a
……………… 중략
[cd001fa8] do_group_exit at c0124487
[cd001fc0] iret_exc at c02d10cf
bt: possible exception frames:
KERNEL-MODE EXCEPTION FRAME AT cd001eec:
EAX: c011e5a3 EBX: 00000206 ECX: c02e36fd EDX: c02e36fd EBP: cd001f40
DS: 007b ESI: f7143e00 ES: 007b EDI: 00000001
CS: 0060 EIP: c02cfd09 ERR: ffffffff EFLAGS: 00010016
USER-MODE EXCEPTION FRAME AT cd001fc4:
EAX: 000000fc EBX: 00000000 ECX: 00000000 EDX: 00000000
DS: 007b ESI: 00000000 ES: 007b EDI: 007a765c
SS: 007b ESP: bff8b358 EBP: bff8b378
CS: 0073 EIP: 0066b7a2 ERR: 000000fc EFLAGS: 00000246
crash> kmem -S inode_cache
CACHE NAME OBJSIZE ALLOCATED TOTAL SLABS SSIZE
f7f47e80 inode_cache 344 697 1056 96 4k
SLAB MEMORY TOTAL ALLOCATED FREE
f7afe080 f7afe0b0 11 3 8
FREE / [ALLOCATED]
f7afe0b0 (cpu 2 cache)
f7afe208 (cpu 2 cache)
f7afe360 (cpu 2 cache)
f7afe4b8 (cpu 2 cache)
f7afe610 (cpu 2 cache)
[f7afe768]
f7afe8c0 (cpu 2 cache)
f7afea18
f7afeb70 (cpu 2 cache)
[f7afecc8]
[f7afee20]
SLAB MEMORY TOTAL ALLOCATED FREE
f6cc2080 f6cc20b0 11 6 5
FREE / [ALLOCATED]
[f6cc20b0]
f6cc2208
………. 중략
SLAB MEMORY TOTAL ALLOCATED FREE
f7f4f000 f7f4f030 11 11 0
FREE / [ALLOCATED]
[f7f4f030]
[f7f4f188]
[f7f4f2e0]
[f7f4f438]
[f7f4f590]
[f7f4f6e8]
crash> inode.i_mem f7f4f030
i_sem = {
count = {
counter = 1
},
sleepers = 0,
wait = {
lock = {
lock = 1,
magic = 0xdead4ead
},
task_list = {
next = 0xf7f4f0b0,
prev = 0xf7f4f0b0
}
}
},
crash> foreach bt
PID: 0 TASK: c031ea80 CPU: 0 COMMAND: “swapper”
#0 [c038ff88] schedule at c02cf361
#1 [c038ffe8] cpu_idle at c01040ab
PID: 0 TASK: f7f210b0 CPU: 1 COMMAND: “swapper”
#0 [c7666f7c] smp_call_function_interrupt at c0116c4a
#1 [c7666f84] irq_entries_start at c02d1ae9
#2 [c7666fc0] cpu_idle at c010409b
PID: 0 TASK: f7f20b30 CPU: 2 COMMAND: “swapper”
#0 [c7668f7c] smp_call_function_interrupt at c0116c4a
#1 [c7668f84] irq_entries_start at c02d1ae9
#2 [c7668fc0] cpu_idle at c010409b
PID: 0 TASK: f7f205b0 CPU: 3 COMMAND: “swapper”
#0 [c7669f7c] smp_call_function_interrupt at c0116c4a
#1 [c7669f84] irq_entries_start at c02d1ae9
#2 [c7669fc0] cpu_idle at c010409b
PID: 1 TASK: f7f21630 CPU: 3 COMMAND: “init”
bt: cannot resolve stack trace:
#0 [c7663e68] schedule at c02cf361
#1 [c7663e84] buffered_rmqueue at c014304b
……….. 중략
crash>
위의 과정들을 거친 끝에 우리는 irq_balance 등이 이루어져 cpu 자원의 (멀티코어 및 멀티CPUs) 할당이 이루어지는 도중
spinlock 의 문제로 커널패닉이 떨어졌음을 확인 할 수 있다.
위 문제에 대한 해답은 뚜렷하게 얻지 못했지만, SMP 커널의 spinlock 문제라는 것을 알았으므로,
kernel.org 혹은 redhat 에서 버그를 찾아 볼 힌트가 생겼으며, 커널의 업데이트를 고객에게 권고할 수 있게 되었다.
kernel.org 등에서 리포팅되어있는 버그로 보여지며, 완전한 해결책은 나와있지 않았으나,
RHEL 이므로 RedHat 의 패치가 이루어 졌을 수도 있으니, 정식 update 를 권장하였다.
Coredump Analysis 2#
상황#
Mailserver 가 자꾸 뻗습니다… 라는 고객의 다소 황망스러운 요청….
결국 히스토리나 기타 정보들이 없다보니 덤프분석뿐이라는 결론으로 덤프 분석에 들어간다.
OS : RHEL 3 Update 8 ( Kernel Ver. 2.4.21-47.ELhugemem
분석과정#
KERNEL: vmlinux2.4.2147.ELhugemem
DEBUGINFO: ./vmlinux2.4.2147.ELhugemem.debug
DUMPFILE: vmcore
CPUS: 8
DATE: Wed Apr 16 06:52:58 2008
UPTIME: 14:34:12
LOAD AVERAGE: 0.48, 0.21, 0.13
TASKS: 206
NODENAME: ***min02.*****.co.kr
RELEASE: 2.4.2147.ELhugemem
VERSION: #1 SMP Wed Jul 5 20:30:35 EDT 2006
MACHINE: i686 (3669 Mhz)
MEMORY: 16.8 GB
PANIC: “”
PID: 20093
COMMAND: “save”
TASK: bd0c0000
CPU: 1
STATE: TASK_RUNNING (PANIC)
crash> bt
PID: 20093 TASK: bd0c0000 CPU: 1 COMMAND: “save”
#0 [bd0c1cf0] netconsole_netdump at f9384783
#1 [bd0c1d04] try_crashdump at 2129783
#2 [bd0c1d14] die at 210cdc2
#3 [bd0c1d28] do_invalid_op at 210cfd2
#4 [bd0c1dc8] error_code (via invalid_op) at 22ad29d
EAX: 00000053 EBX: 00000010 ECX: 000f6000 EDX: 0015b8f0 EBP: 0817586c
DS: 0068 ESI: 023a9408 ES: 0068 EDI: 023a8200
CS: 0060 EIP: 02159f7d ERR: ffffffff EFLAGS: 00010006
#5 [bd0c1e04] rmqueue at 2159f7d
#6 [bd0c1e40] __alloc_pages_limit at 215a268
#7 [bd0c1e58] __alloc_pages at 215a36f
…….. 중략 …………
#14 [bd0c1fc0] system_call at 22ad091
EAX: 00000003 EBX: 0000000e ECX: 08324000 EDX: 00010000
DS: 002b ESI: 0814c790 ES: 002b EDI: fefff440
SS: 002b ESP: feff10c8 EBP: 00000000
CS: 0023 EIP: f65deb7e ERR: 00000003 EFLAGS: 00000246
crash> rd 08175860 40
175860: 44445320 362e3120 302e322e 3220312d SDD 1.6.2.01 2
8175870: 322e342e 37342d31 634c452e 6f747375 .4.2147.ELcusto
8175880: 4d53206d 53202050 31207065 30322032 m SMP Sep 12 20
8175890: 32203630 37313a30 2037323a 20294328 06 20:17:27 (C)
81758a0: 204d4249 70726f43 00000a2e 00000000 IBM Corp……..
81758b0: 00000000 00000000 00000000 00000000 …………….
81758c0: 02001000 00000000 00000000 00000000 …………….
81758d0: 00000000 00000000 00000000 00000000 …………….
81758e0: 00000000 00000000 00000000 00000000 …………….
81758f0: 00000000 00000000 00000000 02001000 …………….
crash>
사실 이번 케이스는 과정을 매우 중략시켰다. 왜?? 사실 이 케이스는 내가 직접 코어분석을 한 부분이아니고,
다른 사람의 분석자료를 긁어다 붙혔기때문이랄까…(먼산 ㅡ.,ㅡ:: )
아무튼 이 분석의 결과는 IBM sdd 드라이버의 문제로 추정되었고, 고객에게 IBM sdd 드라이버를 업데이트
하는 것으로 마무리 되었다.
뭐 자세한 이유를 설명하자면 위에서 bt 과정에서 rmqueue 부분에서 시스템 패닉이 발생되었음을
알 수 있었고, rmqueue 는 장치(block)를 해제(free)시켜주는 시스템 콜인데, 정상적으로 해제 하지 못한 장치가
있었다는 의미며, 이때당시의 EBP 메모리 주소의 내용을 넓은 범위로 까보니 ( rd 08175860 40 )
SDD 드라이버의 버젼정보가 남아있는 것으로 보아, 커널에서 이 드라이버와 관계된 작업을 정상적으로
Page 재할당 혹은 해제 하지 못했음을 추정 할 수 있었던 게다…..
Coredump Analysis 3#
상황#
기존 1번 상황과 같은 엔드유저.
상황은 저번과 다르나 nfs 관련된 서버들이 이상하게 자꾸 뻗는 현상 발생.
역시 그냥 뻗었다면서 sysreport 와 커널덤프파일만 보내온상황..
시스템 (OS) : RedHat Enterprise Linux 4 WS
Kernel Ver. : 2.6.9-22.ELsmp
Machine : i686
Memory : 2G
분석과정#
[root@LDS-Mirr debuginfo]# crash 2.6.9-22.ELsmp/vmlinux vmcore
crash 4.0-8.7.2.fc11
Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009 Red Hat, Inc.
Copyright (C) 2004, 2005, 2006 IBM Corporation
중략…
WARNING: kernels compiled by different gcc versions:
2.6.9-22.ELsmp/vmlinux: 3.4.6
vmcore kernel: 3.4.4
please wait… (gathering kmem slab cache data)
please wait… (gathering module symbol data)
please wait… (gathering task table data)
please wait… (determining panic task)
KERNEL: 2.6.9-22.ELsmp/vmlinux
DUMPFILE: vmcore
CPUS: 2
DATE: Fri Nov 6 05:38:14 2009
UPTIME: 1478 days, 15:46:30
LOAD AVERAGE: 2.60, 2.44, 2.25
TASKS: 126
NODENAME: *******3
RELEASE: 2.6.9-22.ELsmp
VERSION: #1 SMP Mon Sep 19 18:32:14 EDT 2005
MACHINE: i686 (2993 Mhz)
MEMORY: 2 GB
PANIC: “Oops: 0002 [#1]” (check log for details)
PID: 21797
COMMAND: “nodemon”
TASK: db976d30 [THREAD_INFO: d0b03000]
CPU: 0
STATE: TASK_RUNNING (PANIC)
crash> bt
PID: 21797 TASK: db976d30 CPU: 0 COMMAND: “nodemon”
#0 [c03c7e60] netpoll_start_netdump at f89ac570
#1 [c03c7e80] die at c0106015
— <soft IRQ> —
bt: cannot resolve stack trace:
bt: text symbols on stack:
[d0b03e78] try_crashdump at c013403d
[d0b03e80] die at c010601a
[d0b03e98] vprintk at c0122459
[d0b03eac] __is_prefetch at c011ac2d
[d0b03eb4] do_page_fault at c011b01d
[d0b03ec4] process_backlog at c027e357
[d0b03ef8] tcp_v4_hnd_req at c02aba3e
[d0b03f08] tcp_v4_rcv at c02abfff
[d0b03f30] sk_common_release at c0278b71
[d0b03f48] e1000_alloc_rx_buffers at f890b4b9
[d0b03f50] ip_rcv at c02947a8
[d0b03f78] e1000_clean_rx_irq at f890b08f
[d0b03f8c] __is_prefetch at c011ac2d
[d0b03f94] irq_entries_start at c02d1bab
[d0b03fc8] process_backlog at c027e357
[d0b03fe8] __do_softirq at c0126424
[d0b03ffc] do_softirq at c010812f
bt: possible exception frame:
KERNEL-MODE EXCEPTION FRAME AT d0b03fa0:
EAX: 00100100 EBX: f76ac100 ECX: f76ac3d0 EDX: 00200200 EBP: bed4a876
DS: 007b ESI: f76ac000 ES: 007b EDI: c201fc80
CS: 0060 EIP: c027e357 ERR: ffffffff EFLAGS: 00010002
crash> log
t_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif
audit(1256135118.410:55140): avc: denied { rawip_recv } for pid=5672 comm=”nodemon” saddr=100.100.1.94 daddr=100.100.1.15 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif
audit(1256135118.410:55141): avc: denied { rawip_recv } for pid=23125 comm=”rrd_ipnms” saddr=100.100.1.94 daddr=100.100.1.15 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif
audit(1256135118.410:55142): avc: denied { rawip_recv } for pid=5684 comm=”nodemon” saddr=119.68.77.13 daddr=58.78.0.216 netif=eth1 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth1_t tclass=netif
audit(1256135118.410:55143): avc: denied { rawip_recv } for pid=5672 comm=”nodemon” saddr=100.100.1.94 daddr=100.100.1.15 netif=eth0 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth0_t tclass=netif
…중략…
audit(1257432919.050:55697): avc: denied { rawip_recv } for pid=5537 comm=”fping” saddr=116.40.65.2 daddr=58.78.0.216 netif=eth1 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth1_t tclass=netif
audit(1257447387.260:55698): avc: denied { rawip_recv } for pid=7068 comm=”fping” saddr=124.48.76.138 daddr=58.78.0.216 netif=eth1 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth1_t tclass=netif
audit(1257453494.395:55699): avc: denied { rawip_recv } for pid=21796 comm=”fping” saddr=122.33.123.169 daddr=58.78.0.216 netif=eth1 scontext=system_u:object_r:unlabeled_t tcontext=system_u:object_r:netif_eth1_t tclass=netif
Unable to handle kernel paging request at virtual address 00100104
— MORE — forward: <SPACE>, <ENTER> or j backward: b or k quit: q printing eip:
c027e357
*pde = 29f2a001
Oops: 0002 [#1]
SMP
Modules linked in: netconsole netdump ipmi_poweroff ipmi_si ipmi_devintf ipmi_msghandler md5 ipv6 parport_pc lp parport autofs4 i2c_dev i2c_core nfs lockd sunrpc dm_mod button battery ac uhci_hcd ehci_hcd hw_random e1000 floppy ext3 jbd gdth sd_mod scsi_mod
CPU: 0
EIP: 0060:[<c027e357>] Not tainted VLI
EFLAGS: 00010002 (2.6.9-22.ELsmp)
EIP is at net_rx_action+0x6b/0xd8
eax: 00100100 ebx: f76ac100 ecx: f76ac3d0 edx: 00200200
esi: f76ac000 edi: c201fc80 ebp: bed4a876 esp: c03c7fd4
ds: 007b es: 007b ss: 0068
Process nodemon (pid: 21797, threadinfo=c03c7000 task=db976d30)
Stack: 00000129 00000001 c038db98 0000000a 00000000 c0126424 d0b03e18 00000046
c038a880 d0b03000 c010812f
Call Trace:
[<c0126424>] __do_softirq+0x4c/0xb1
[<c010812f>] do_softirq+0x4f/0x56
=======================
[<c0107a44>] do_IRQ+0x1a2/0x1ae
[<c02d1a8c>] common_interrupt+0x18/0x20
[<c014c747>] do_wp_page+0x1af/0x371
[<c014d562>] handle_mm_fault+0x11c/0x175
[<c011addb>] do_page_fault+0x1ae/0x5c6
[<c011cbba>] recalc_task_prio+0x128/0x133
[<c011d3d5>] finish_task_switch+0x30/0x66
[<c02cf368>] schedule+0x844/0x87a
[<c0107a44>] do_IRQ+0x1a2/0x1ae
[<c011ac2d>] do_page_fault+0x0/0x5c6
[<c02d1bab>] error_code+0x2f/0x38
[<c02d007b>] __lock_text_end+0x11a/0x100f
— MORE — forward: <SPACE>, <ENTER> or j backward: b or k quit: q Code: f8 01 77 6c fb 8b 5f 20 8d b3 00 ff ff ff 83 be 08 01 00 00 00 7e 0e 89 e2 89 f0 ff 96 7c 01 00 00 85 c0 74 3d fa 8b 53 04 8b 03 <89> 50 04 89 02 8d 47 20 c7 43 04 00 02 20 00 8b 50 04 89 03 89
길다. 대략 요즘 보면 RedHat 에스컬레이션 시 분석엔지니어가 log 명령을 통해 상세한 로그를 얻어서 분석하던데,
나도 따라해 봤다. 일반 sysreport 에서 남겨지는 message 로그와는 확연히 다른 상세 로그가 남았다.
crash> runq
RUNQUEUES[0]: c201dd60
ACTIVE PRIO_ARRAY: c201dd9c
[117] PID: 21797 TASK: db976d30 CPU: 0 COMMAND: “nodemon”
[134] PID: 3 TASK: f7e005b0 CPU: 0 COMMAND: “ksoftirqd/0”
EXPIRED PRIO_ARRAY: c201e214
RUNQUEUES[1]: c2025d60
ACTIVE PRIO_ARRAY: c2026214
EXPIRED PRIO_ARRAY: c2025d9c
역시 가장 마지막 실행된 데몬 혹은 명령은 nodemon 이라는 녀석이다.
crash> ps
PID PPID CPU TASK ST %MEM VSZ RSS COMM
0 0 0 c031ea80 RU 0.0 0 0 [swapper]
> 0 1 1 f7e010b0 RU 0.0 0 0 [swapper]
1 0 1 f7e01630 IN 0.0 3164 560 init
2 1 0 f7e00b30 IN 0.0 0 0 [migration/0]
3 1 0 f7e005b0 RU 0.0 0 0 [ksoftirqd/0]
4 1 1 f7e00030 IN 0.0 0 0 [migration/1]
5 1 1 f7e456b0 IN 0.0 0 0 [ksoftirqd/1]
6 1 0 f7e45130 IN 0.0 0 0 [events/0]
7 1 1 f7e44bb0 IN 0.0 0 0 [events/1]
8 6 0 f7e44630 IN 0.0 0 0 [khelper]
9 6 0 f7e440b0 IN 0.0 0 0 [kacpid]
35 6 0 f7cd5730 IN 0.0 0 0 [kblockd/0]
36 6 1 f7cd51b0 IN 0.0 0 0 [kblockd/1]
….중략…..
21795 21788 1 c2348db0 IN 0.0 1496 512 fping
21796 21789 1 f54e4cb0 IN 0.0 1496 512 fping
> 21797 21790 0 db976d30 RU 0.5 1915760 11156 nodemon
21798 21791 1 f6725430 UN 0.5 1915760 11156 nodemon
22557 1 1 e148c830 IN 0.0 0 0 [rpciod]
22558 1 1 c27e63b0 IN 0.0 0 0 [lockd]
23100 2522 1 f3716330 IN 0.1 4364 1104 crond
23101 23100 0 f37173b0 DE 0.0 0 0 perfmgr_all.sh
23114 1 1 f5ca23b0 IN 0.1 6736 1144 perfmgr_all.sh
23117 23114 1 f5ca2930 IN 0.1 5708 1156 perfmgr
23125 23117 1 f37168b0 UN 0.1 4228 2632 rrd_ipnms
24432 1 1 f67259b0 IN 0.0 2672 808 neoctrld
24433 24432 0 f6724930 IN 0.0 2008 944 neozmond
24434 24432 0 f47b2030 IN 0.0 3576 884 neopmond
24435 24432 1 f3acb930 IN 0.0 2304 772 neosmond
24436 24432 0 f3acae30 IN 0.0 2420 756 neormond
24437 24432 1 f634cc30 IN 0.0 3212 648 neocmond
24438 24432 1 f634d1b0 IN 0.0 2800 732 neoemond
24865 2377 0 ee47ebb0 IN 0.0 3296 652 in.telnetd
24870 24865 1 f76728b0 DE 0.0 0 0 login
27098 1 0 c27e6eb0 IN 1.4 42536 29200 poller
27152 1 1 e7a76930 IN 1.8 51732 37544 poller
28254 1 0 f75e46b0 IN 0.2 10404 3696 cupsd
ps 로 확인 해 보았을 때 역시 표시가 있고,
crash> bt 21797
PID: 21797 TASK: db976d30 CPU: 0 COMMAND: “nodemon”
#0 [c03c7e60] netpoll_start_netdump at f89ac570
#1 [c03c7e80] die at c0106015
— <soft IRQ> —
bt: cannot resolve stack trace:
bt: text symbols on stack:
[d0b03e78] try_crashdump at c013403d
[d0b03e80] die at c010601a
[d0b03e98] vprintk at c0122459
[d0b03eac] __is_prefetch at c011ac2d
[d0b03eb4] do_page_fault at c011b01d
[d0b03ec4] process_backlog at c027e357
[d0b03ef8] tcp_v4_hnd_req at c02aba3e
[d0b03f08] tcp_v4_rcv at c02abfff
[d0b03f30] sk_common_release at c0278b71
[d0b03f48] e1000_alloc_rx_buffers at f890b4b9
[d0b03f50] ip_rcv at c02947a8
[d0b03f78] e1000_clean_rx_irq at f890b08f
[d0b03f8c] __is_prefetch at c011ac2d
[d0b03f94] irq_entries_start at c02d1bab
[d0b03fc8] process_backlog at c027e357
[d0b03fe8] __do_softirq at c0126424
[d0b03ffc] do_softirq at c010812f
bt: possible exception frame:
KERNEL-MODE EXCEPTION FRAME AT d0b03fa0:
EAX: 00100100 EBX: f76ac100 ECX: f76ac3d0 EDX: 00200200 EBP: bed4a876
DS: 007b ESI: f76ac000 ES: 007b EDI: c201fc80
CS: 0060 EIP: c027e357 ERR: ffffffff EFLAGS: 00010002
backtrace 로 찍어 보았다. 잘 보면 스택부분에 크게 의심될만한 호출은 없는 것 같다.
한가지 있다면 backlog 부분과 page_fault … 약간 의심이 가기 시작한다.
crash> task
PID: 21797 TASK: db976d30 CPU: 0 COMMAND: “nodemon”
struct task_struct {
state = 0,
thread_info = 0xd0b03000,
usage = {
counter = 2
},
flags = 64,
ptrace = 0,
lock_depth = -1,
prio = 117,
static_prio = 120,
run_list = {
next = 0xc201e15c,
prev = 0xc201e15c
},
array = 0xc201dd9c,
sleep_avg = 797645007,
interactive_credit = 0,
timestamp = 1565221201025565,
last_ran = 1565221200988322,
… 중략 …
rlim = {{
rlim_cur = 4294967295,
rlim_max = 4294967295
…. 생략 …
task 를 찍어보았더니 너무 길다. 저번과 같이 deadbeef 같은 번지수는 찾아지지 않았다.
다만 rlim 값이 current 와 max 가 동일한 듯한 느낌이 든다.
crash> timer
TVEC_BASES[0]: c201e760
JIFFIES
3201639042
EXPIRES TIMER_LIST FUNCTION
3201607813 f759d8b4 c0257180 <rh_call_control+611>
3201607813 f755a228 f887fa6d <stall_callback>
3201607824 e4818c7c c02a81df <tcp_out_of_resources+352>
3201607836 d7286c7c c02a81df <tcp_out_of_resources+352>
3201607838 e585b57c c02a81df <tcp_out_of_resources+352>
3201607846 f7670a28 f887fa6d <stall_callback>
3201607887 f76708b4 c0257180 <rh_call_control+611>
3201607892 efb0df64 c0129fba <sys_getegid+4>
… 중략 …
3201715193 e07adecc c0129fba <sys_getegid+4>
3201863941 f6c9bf64 c0129fba <sys_getegid+4>
3202207798 c0447ba0 c020a242 <do_blank_screen+476>
3202500736 f686cef0 c01258b3 <sys_getitimer+102>
3202531229 f757f7f0 c01258b3 <sys_getitimer+102>
— MORE — forward: <SPACE>, <ENTER> or j backward: b or k quit: q
3207355798 f2d37390 c02a8a54 <tcp_synack_timer+200>
잘모르겠는데 타이머를 한번 찍어보았다.
역시 대략 특이한 점은 찾을 수 없었다.
bt 로 나왔던 몇몇 주소들을 dis 명령으로 disassembler 해본다.
crash> dis c027e357 100
0xc027e357 <process_backlog+44>: mov %edx,0x4(%eax)
0xc027e35a <process_backlog+47>: mov %eax,(%edx)
0xc027e35c <process_backlog+49>: lea 0x20(%edi),%eax
0xc027e35f <process_backlog+52>: movl $0x200200,0x4(%ebx)
0xc027e366 <process_backlog+59>: mov 0x4(%eax),%edx
0xc027e369 <process_backlog+62>: mov %eax,(%ebx)
0xc027e36b <process_backlog+64>: mov %ebx,0x4(%eax)
… 중략 …
0xc027e40d <process_backlog+226>: test %eax,%eax
0xc027e40f <process_backlog+228>: je 0xc027e423 <process_backlog+248>
0xc027e411 <process_backlog+230>: xor %eax,%eax
0xc027e413 <process_backlog+232>: mov $0x8,%ecx
0xc027e418 <process_backlog+237>: lea 0x0(%esp),%edi
— MORE — forward: <SPACE>, <ENTER> or j backward: b or k quit: q 0xc027e41c <process_backlog+241>: repz stos %eax,%es:(%edi)
0xc027e41e <process_backlog+243>: jmp 0xc027e4b2 <net_rx_action+138>
0xc027e423 <process_backlog+248>: mov $0x20,%ecx
0xc027e428 <net_rx_action>: mov %ebx,%edx
0xc027e42a <net_rx_action+2>: lea 0x0(%esp),%eax
0xc027e42e <net_rx_action+6>: call 0xc01c1ca0 <__copy_user_zeroing_intel+46>
0xc027e433 <net_rx_action+11>: test %eax,%eax
0xc027e435 <net_rx_action+13>: jne 0xc027e4b2 <net_rx_action+138>
0xc027e437 <net_rx_action+15>: mov $0xc034824c,%eax
0xc027e43c <net_rx_action+20>: call 0xc02cfc99 <rwsem_down_write_failed+153>
0xc027e441 <net_rx_action+25>: mov 0x10(%esp),%eax
0xc027e445 <net_rx_action+29>: call 0xc027d197 <netdev_boot_setup_check+141>
0xc027e44a <net_rx_action+34>: test %eax,%eax
0xc027e44c <net_rx_action+36>: mov %eax,%esi
0xc027e44e <net_rx_action+38>: jne 0xc027e461 <net_rx_action+57>
0xc027e450 <net_rx_action+40>: mov $0xc034824c,%eax
0xc027e455 <net_rx_action+45>: call 0xc02cfce5 <rwsem_down_write_failed+229>
0xc027e45a <net_rx_action+50>: mov $0xffffffed,%edx
0xc027e45f <net_rx_action+55>: jmp 0xc027e4b7 <net_rx_action+143>
0xc027e461 <net_rx_action+57>: lea 0x0(%esp),%edi
0xc027e465 <net_rx_action+61>: lods %ds:(%esi),%al
0xc027e466 <net_rx_action+62>: stos %al,%es:(%edi)
0xc027e467 <net_rx_action+63>: test %al,%al
0xc027e469 <net_rx_action+65>: jne 0xc027e465 <net_rx_action+61>
0xc027e46b <net_rx_action+67>: mov $0xc034824c,%eax
0xc027e470 <net_rx_action+72>: call 0xc02cfce5 <rwsem_down_write_failed+229>
0xc027e475 <net_rx_action+77>: xor %ecx,%ecx
0xc027e477 <net_rx_action+79>: mov $0x213,%edx
0xc027e47c <net_rx_action+84>: mov $0xc02dae65,%eax
0xc027e481 <net_rx_action+89>: call 0xc011fc54 <in_sched_functions+33>
0xc027e486 <net_rx_action+94>: call 0xc02cf6cf <interruptible_sleep_on_timeout+88>
0xc027e48b <net_rx_action+99>: mov %ebx,%edx
0xc027e48d <net_rx_action+101>: add $0x20,%edx
— MORE — forward: <SPACE>, <ENTER> or j backward: b or k quit: q
0xc027e490 <net_rx_action+104>: sbb %eax,%eax
딱히 이상해 보이는 어셈부분은 없었다.
이번 사례는 아직 에스컬레이션 진행중이고 답은 아직 멀었지만 R 모사의 분석이 나오기 전에
케이스 연습삼아 작성 해 보았다.
일단 내가 예상하는 원인으로는 일단 selinux 가 동작중이며,
nodemon 이라는 녀석이 selinux 로 인해 네트워크쪽 오버헤드를 일으키는 부분이 있는 것 같고,
그로 인한 백로그 상승등이 시스템 Hang Up 상황을 만들지 않았을까 하는데,
어플리케이션의 버그 일수도 있지 않나 싶다.
일단 어떤 해결안에 대한 권고를 해야한다면 selinux 를 꺼보시고 커널파라메터튜닝등을 통해
백로그를 조금 더 잡아주는 것을 권고 해 봐야 겠지…
레드햇 답변 나오면 확인해봐야겠다.. 이렇게 커널분석부분도 케이스를 모아놓으면 도움이 되지 않을까 한다.
-> 레드햇 답변으로는 버그질라 477202 와 동일상황으로 보았다. ( net_rx_action 함수의 race condition 버그 )
즉 커널 업데이트를 권고하는데 4.8 이상으로 음….EIP 에서 나온 함수를 버그질라에서 검색한건가 보네…
미처 생각 못했던 건데….아무튼 대단하긴 하다 ㅡ,.ㅡ::
Coredump Analysis 4#
상황#
이번 엔드유저는 다른 엔드유저. 64G, 64비트 환경의 오라클 디비 서버란다.
한달사이에 세번이나 연속되서 리부팅이 이루어 졌다.
시스템 (OS) : RedHat Enterprise Linux 5 Server update 3
Kernel Ver. : 2.6.18-128.ELsmp
Machine : x86_64
Memory : 64G
분석과정#
KERNEL: /usr/lib/debug/lib/modules/2.6.18-128.el5/vmlinux
DUMPFILE: vmcore
CPUS: 24
DATE: Thu Dec 10 22:26:28 2009
UPTIME: 34 days, 09:18:38
LOAD AVERAGE: 0.18, 0.12, 0.03
TASKS: 476
NODENAME: *******
RELEASE: 2.6.18-128.el5
VERSION: #1 SMP Wed Dec 17 11:41:38 EST 2008
MACHINE: x86_64 (2665 Mhz)
MEMORY: 63.1 GB
PANIC: “”
PID: 29298
COMMAND: “oracle”
TASK: ffff8110760ea040 [THREAD_INFO: ffff810f2965a000]
CPU: 0
STATE: TASK_RUNNING (PANIC)
crash> bt
PID: 29298 TASK: ffff8110760ea040 CPU: 0 COMMAND: “oracle”
#0 [ffffffff804259a0] crash_kexec at ffffffff800aaa0c
#1 [ffffffff80425a60] __die at ffffffff8006520f
#2 [ffffffff80425aa0] die at ffffffff8006bc17
#3 [ffffffff80425ad0] do_invalid_op at ffffffff8006c1d7
#4 [ffffffff80425b90] error_exit at ffffffff8005dde9
[exception RIP: end_page_writeback+36]
RIP: ffffffff80039b4c RSP: ffffffff80425c40 RFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8101393e8690 RCX: 0000000000000034
RDX: ffff81105b1d02b0 RSI: 0000000000000286 RDI: ffff81105fa99868
RBP: ffff81105b1d02b0 R8: ffff8108120495b0 R9: ffff81107ef0b000
R10: ffff810743c7f540 R11: ffffffff800419ac R12: 0000000000000202
R13: ffff8101393e8690 R14: 00000001b11317db R15: 0000000000003000
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#5 [ffffffff80425c48] end_buffer_async_write at ffffffff80045431
#6 [ffffffff80425c98] end_bio_bh_io_sync at ffffffff800419db
#7 [ffffffff80425ca8] dec_pending at ffffffff88182386
#8 [ffffffff80425cd8] clone_endio at ffffffff8818255a
#9 [ffffffff80425d08] dec_pending at ffffffff88182386
#10 [ffffffff80425d38] clone_endio at ffffffff8818255a
#11 [ffffffff80425d68] dec_pending at ffffffff88182386
#12 [ffffffff80425d98] clone_endio at ffffffff8818255a
#13 [ffffffff80425dc8] __end_that_request_first at ffffffff8002ca64
#14 [ffffffff80425e58] scsi_io_completion at ffffffff8807a1a8
#15 [ffffffff80425eb8] sd_rw_intr at ffffffff880a67cd
#16 [ffffffff80425f18] blk_done_softirq at ffffffff800376ff
#17 [ffffffff80425f38] __do_softirq at ffffffff80011fbc
#18 [ffffffff80425f68] call_softirq at ffffffff8005e2fc
#19 [ffffffff80425f80] do_softirq at ffffffff8006cada
#20 [ffffffff80425f90] do_IRQ at ffffffff8006c962
— <IRQ stack> —
#21 [ffff810f2965b818] ret_from_intr at ffffffff8005d615
[exception RIP: dm_table_put+20]
RIP: ffffffff88183d5b RSP: ffff810f2965b8c8 RFLAGS: 00000202
RAX: 0000000000000000 RBX: ffff81107a9c8800 RCX: c000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff810139ea4e00
RBP: ffff810742b09a08 R8: ffff81107bbcd800 R9: ffff810776208b08
R10: ffff81107ef0b000 R11: ffffffff80146083 R12: ffff81107a9c8800
R13: 0000000000000000 R14: ffffffff88182465 R15: 000000000fd00001
ORIG_RAX: ffffffffffffffcd CS: 0010 SS: 0018
#22 [ffff810f2965b8e0] dm_request at ffffffff8818394c
….. 중략
#37 [ffff810f2965bde0] ext3_file_write at ffffffff8804c18e
#38 [ffff810f2965be00] do_sync_write at ffffffff80017d2d
#39 [ffff810f2965bf10] vfs_write at ffffffff8001659e
#40 [ffff810f2965bf40] sys_pwrite64 at ffffffff80043876
#41 [ffff810f2965bf80] system_call at ffffffff8005d116
RIP: 00000037eda0de33 RSP: 00007fffc74a15c0 RFLAGS: 00000206
RAX: 0000000000000012 RBX: ffffffff8005d116 RCX: 0000000000000371
RDX: 0000000000100000 RSI: 0000000060bcbc00 RDI: 0000000000000013
RBP: 0000000000000200 R8: 00000000bc67e0f0 R9: 0000000060bcbc00
R10: 00000000024fb800 R11: 0000000000000246 R12: 00000000000127db
R13: 00007fffc74a1160 R14: 00002b24e53e45a8 R15: 00000000c74a1310
ORIG_RAX: 0000000000000012 CS: 0033 SS: 002b
crash>
더럽게 길다. 게다가 자꾸 I/O 및 파일시스템 관련 시스템콜만 더럽게 불러대끼고 있으며,
우리가 원하는 EIP 등은 눈을 씻고 찾아봐도 나오질 않는다.
그렇다 이건 64비트..확장된 레지스터를 사용하기 때문에 기존 E 자들은 R 자로 변경되었다 (쉽게쉽게~)
자 RIP 가 보인다. 보면 page_writeback 시스템콜등 디스크에 기록하는 부분들에서 멈춰댔다.
실제 이 것들만 보면 리부팅의 원인은 페이지 기록 즉 디스크에 기록하는 작업에서 문제가 발생한것으로
생각할 수 있다. 로그를 보자.
usb-storage: device scan complete
usb 1-7: USB disconnect, address 4
———– [cut here ] ——— [please bite here ] ———
Kernel BUG at mm/filemap.c:568
invalid opcode: 0000 [1] SMP
last sysfs file: /devices/pci0000:00/0000:00:1c.0/resource
CPU 0
Modules linked in: vfat fat usb_storage iptable_mangle iptable_nat ip_nat ip_con
ntrack nfnetlink iptable_filter ip_tables x_tables ipv6 xfrm_nalgo crypto_api au
tofs4 sunrpc ib_iser rdma_cm ib_cm iw_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp
libiscsi scsi_transport_iscsi dm_mirror dm_round_robin dm_multipath scsi_dh vide
o hwmon backlight sbs i2c_ec i2c_core button battery asus_acpi acpi_memhotplug a
c parport_pc lp parport joydev sg shpchp ide_cd cdrom e1000e bnx2 pcspkr dm_raid
45 dm_message dm_region_hash dm_log dm_mod dm_mem_cache lpfc scsi_transport_fc a
ta_piix libata megaraid_sas sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd
Pid: 29298, comm: oracle Not tainted 2.6.18-128.el5 #1
RIP: 0010:[<ffffffff80039b4c>] [<ffffffff80039b4c>] end_page_writeback+0x24/0x4
7
RSP: 0018:ffffffff80425c40 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff8101393e8690 RCX: 0000000000000034
RDX: ffff81105b1d02b0 RSI: 0000000000000286 RDI: ffff81105fa99868
RBP: ffff81105b1d02b0 R08: ffff8108120495b0 R09: ffff81107ef0b000
R10: ffff810743c7f540 R11: ffffffff800419ac R12: 0000000000000202
R13: ffff8101393e8690 R14: 00000001b11317db R15: 0000000000003000
FS: 00002b24e5219c40(0000) GS:ffffffff803ac000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 0000000071009fac CR3: 0000000f29821000 CR4: 00000000000006e0
Process oracle (pid: 29298, threadinfo ffff810f2965a000, task ffff8110760ea040)
Stack: ffff81105b1d02b0 ffffffff80045431 ffff810743c7f340 0000000000000246
0000000000000001 ffff810743c7f340 ffff810743c7f340 ffff8107343965c0
ffff810752d02ec0 0000000000000001 0000000000000001 ffffffff800419db
Call Trace:
<IRQ> [<ffffffff80045431>] end_buffer_async_write+0xff/0x126
[<ffffffff800419db>] end_bio_bh_io_sync+0x2f/0x3b
[<ffffffff88182386>] :dm_mod:dec_pending+0x170/0x194
[<ffffffff8818255a>] :dm_mod:clone_endio+0x97/0xc5
[<ffffffff88182386>] :dm_mod:dec_pending+0x170/0x194
[<ffffffff8818255a>] :dm_mod:clone_endio+0x97/0xc5
[<ffffffff88182386>] :dm_mod:dec_pending+0x170/0x194
[<ffffffff8818255a>] :dm_mod:clone_endio+0x97/0xc5
[<ffffffff8002ca64>] __end_that_request_first+0x265/0x5df
[<ffffffff8005bd2f>] blk_run_queue+0x28/0x72
[<ffffffff88079fb4>] :scsi_mod:scsi_end_request+0x27/0xcd
[<ffffffff8807a1a8>] :scsi_mod:scsi_io_completion+0x14e/0x324
[<ffffffff880a67cd>] :sd_mod:sd_rw_intr+0x21d/0x257
[<ffffffff88125117>] :lpfc:lpfc_intr_handler+0x53d/0x580
[<ffffffff8807a43d>] :scsi_mod:scsi_device_unbusy+0x67/0x81
[<ffffffff800376ff>] blk_done_softirq+0x5f/0x6d
[<ffffffff80011fbc>] __do_softirq+0x89/0x133
[<ffffffff8005e2fc>] call_softirq+0x1c/0x28
[<ffffffff8006cada>] do_softirq+0x2c/0x85
[<ffffffff8006c962>] do_IRQ+0xec/0xf5
[<ffffffff8005d615>] ret_from_intr+0x0/0xa
<EOI> [<ffffffff80146083>] cfq_latter_request+0x0/0x1d
[<ffffffff88183d5b>] :dm_mod:dm_table_put+0x14/0xc5
[<ffffffff8818394c>] :dm_mod:dm_request+0x115/0x124
[<ffffffff8001bd3d>] generic_make_request+0x1d2/0x1e9
[<ffffffff88182465>] :dm_mod:__map_bio+0xbb/0x119
[<ffffffff88182f3c>] :dm_mod:__split_bio+0x188/0x3be
[<ffffffff8818394c>] :dm_mod:dm_request+0x115/0x124
[<ffffffff8001bd3d>] generic_make_request+0x1d2/0x1e9
[<ffffffff80022ba3>] mempool_alloc+0x31/0xe7
[<ffffffff80032e58>] submit_bio+0xcd/0xd4
[<ffffffff8001a357>] submit_bh+0xf1/0x111
[<ffffffff8001bf4a>] __block_write_full_page+0x1f6/0x301
[<ffffffff8804eca5>] :ext3:ext3_get_block+0x0/0xf9
[<ffffffff88050457>] :ext3:ext3_ordered_writepage+0xf1/0x198
[<ffffffff8001cab3>] mpage_writepages+0x1ab/0x34d
[<ffffffff88050366>] :ext3:ext3_ordered_writepage+0x0/0x198
[<ffffffff8005a795>] do_writepages+0x29/0x2f
[<ffffffff8004f4f0>] __filemap_fdatawrite_range+0x50/0x5b
[<ffffffff800c29b8>] sync_page_range+0x3d/0xa1
[<ffffffff8002117e>] generic_file_aio_write+0xa6/0xc1
[<ffffffff8804c18e>] :ext3:ext3_file_write+0x16/0x91
[<ffffffff80017d2d>] do_sync_write+0xc7/0x104
[<ffffffff8009db21>] autoremove_wake_function+0x0/0x2e
[<ffffffff80063097>] thread_return+0x62/0xfe
[<ffffffff8001659e>] vfs_write+0xce/0x174
[<ffffffff80043876>] sys_pwrite64+0x50/0x70
[<ffffffff8005d116>] system_call+0x7e/0x83
Code: 0f 0b 68 af b7 29 80 c2 38 02 48 89 df e8 f1 0b fe ff 48 89
RIP [<ffffffff80039b4c>] end_page_writeback+0x24/0x47
RSP <ffffffff80425c40>
crash>
다 생략하고 끝에 컷 히얼~ 여기만 붙혔다.
역시나 end_page_writeback 즉 page 기록 중에 생긴 문제란다.
결국 dm 사용이 되고 있는지, 벤더 제공 디스크관련 모듈을 사용하고 있지 않은지 확인해 봐야 겠다.
crash> mod
MODULE NAME SIZE OBJECT FILE
ffffffff88007e80 ehci_hcd 65741 (not loaded) [CONFIG_KALLSYMS]
ffffffff88017800 ohci_hcd 55925 (not loaded) [CONFIG_KALLSYMS]
ffffffff88026e00 uhci_hcd 57433 (not loaded) [CONFIG_KALLSYMS]
ffffffff8803fd80 jbd 94257 (not loaded) [CONFIG_KALLSYMS]
ffffffff8806ae00 ext3 168017 (not loaded) [CONFIG_KALLSYMS]
ffffffff8809ca80 scsi_mod 196569 (not loaded) [CONFIG_KALLSYMS]
ffffffff880aba00 sd_mod 56385 (not loaded) [CONFIG_KALLSYMS]
ffffffff880bc880 megaraid_sas 72445 (not loaded) [CONFIG_KALLSYMS]
ffffffff880f2c80 libata 208721 (not loaded) [CONFIG_KALLSYMS]
ffffffff88101c00 ata_piix 56901 (not loaded) [CONFIG_KALLSYMS]
ffffffff88114e00 scsi_transport_fc 73801 (not loaded) [CONFIG_KALLSYMS]
ffffffff8816ce00 lpfc 352909 (not loaded) [CONFIG_KALLSYMS]
ffffffff88178600 dm_mem_cache 38977 (not loaded) [CONFIG_KALLSYMS]
ffffffff88191d80 dm_mod 100369 (not loaded) [CONFIG_KALLSYMS]
ffffffff8819ed00 dm_log 44865 (not loaded) [CONFIG_KALLSYMS]
ffffffff881ab200 dm_region_hash 46145 (not loaded) [CONFIG_KALLSYMS]
ffffffff881b5b00 dm_message 36161 (not loaded) [CONFIG_KALLSYMS]
ffffffff881cf080 dm_raid45 99025 (not loaded) [CONFIG_KALLSYMS]
ffffffff881d9b80 pcspkr 36289 (not loaded) [CONFIG_KALLSYMS]
ffffffff8820e300 bnx2 210249 (not loaded) [CONFIG_KALLSYMS]
ffffffff8821a900 joydev 43969 (not loaded) [CONFIG_KALLSYMS]
ffffffff88242700 e1000e 145809 (not loaded) [CONFIG_KALLSYMS]
ffffffff88256600 cdrom 68713 (not loaded) [CONFIG_KALLSYMS]
ffffffff88269a00 ide_cd 73825 (not loaded) [CONFIG_KALLSYMS]
ffffffff8827d200 shpchp 70765 (not loaded) [CONFIG_KALLSYMS]
ffffffff8828ff00 sg 69993 (not loaded) [CONFIG_KALLSYMS]
ffffffff882a3b00 parport 73165 (not loaded) [CONFIG_KALLSYMS]
ffffffff882b0080 lp 47121 (not loaded) [CONFIG_KALLSYMS]
ffffffff882c1000 parport_pc 62312 (not loaded) [CONFIG_KALLSYMS]
ffffffff882cc500 ac 38729 (not loaded) [CONFIG_KALLSYMS]
ffffffff882d7a80 acpi_memhotplug 40133 (not loaded) [CONFIG_KALLSYMS]
ffffffff882e5480 asus_acpi 50917 (not loaded) [CONFIG_KALLSYMS]
ffffffff882f1900 battery 43849 (not loaded) [CONFIG_KALLSYMS]
ffffffff882fcc00 button 40545 (not loaded) [CONFIG_KALLSYMS]
ffffffff8830b900 i2c_core 56129 (not loaded) [CONFIG_KALLSYMS]
ffffffff88316480 i2c_ec 38593 (not loaded) [CONFIG_KALLSYMS]
ffffffff88324080 sbs 49921 (not loaded) [CONFIG_KALLSYMS]
ffffffff8832f980 backlight 39873 (not loaded) [CONFIG_KALLSYMS]
ffffffff88339c80 hwmon 36553 (not loaded) [CONFIG_KALLSYMS]
ffffffff88347d80 video 53197 (not loaded) [CONFIG_KALLSYMS]
ffffffff88353080 scsi_dh 41665 (not loaded) [CONFIG_KALLSYMS]
ffffffff88362580 dm_multipath 55257 (not loaded) [CONFIG_KALLSYMS]
ffffffff8836cd80 dm_round_robin 36801 (not loaded) [CONFIG_KALLSYMS]
ffffffff8837ad80 dm_mirror 53193 (not loaded) [CONFIG_KALLSYMS]
ffffffff8838c400 scsi_transport_iscsi 67153 (not loaded) [CONFIG_KALLSYMS]
ffffffff8839d600 libiscsi 63553 (not loaded) [CONFIG_KALLSYMS]
ffffffff883ad200 iscsi_tcp 58433 (not loaded) [CONFIG_KALLSYMS]
ffffffff883b9180 ib_addr 41929 (not loaded) [CONFIG_KALLSYMS]
ffffffff883d1b80 ib_core 93637 (not loaded) [CONFIG_KALLSYMS]
ffffffff883e4180 ib_mad 70629 (not loaded) [CONFIG_KALLSYMS]
ffffffff883f7f80 ib_sa 74441 (not loaded) [CONFIG_KALLSYMS]
ffffffff88404780 iw_cm 43465 (not loaded) [CONFIG_KALLSYMS]
ffffffff88416400 ib_cm 67305 (not loaded) [CONFIG_KALLSYMS]
ffffffff88428380 rdma_cm 67157 (not loaded) [CONFIG_KALLSYMS]
ffffffff8843a280 ib_iser 66873 (not loaded) [CONFIG_KALLSYMS]
ffffffff88468800 sunrpc 197897 (not loaded) [CONFIG_KALLSYMS]
ffffffff8847bc80 autofs4 57033 (not loaded) [CONFIG_KALLSYMS]
ffffffff88487580 crypto_api 42945 (not loaded) [CONFIG_KALLSYMS]
ffffffff88493700 xfrm_nalgo 43333 (not loaded) [CONFIG_KALLSYMS]
ffffffff884f9f80 ipv6 424609 (not loaded) [CONFIG_KALLSYMS]
ffffffff8850a280 x_tables 50377 (not loaded) [CONFIG_KALLSYMS]
ffffffff88518d80 ip_tables 55329 (not loaded) [CONFIG_KALLSYMS]
ffffffff88523b00 iptable_filter 36161 (not loaded) [CONFIG_KALLSYMS]
ffffffff8852eb80 nfnetlink 40457 (not loaded) [CONFIG_KALLSYMS]
ffffffff88545800 ip_conntrack 91109 (not loaded) [CONFIG_KALLSYMS]
ffffffff88554400 ip_nat 52845 (not loaded) [CONFIG_KALLSYMS]
ffffffff8855fd00 iptable_nat 40773 (not loaded) [CONFIG_KALLSYMS]
ffffffff88569a80 iptable_mangle 36033 (not loaded) [CONFIG_KALLSYMS]
ffffffff88587100 usb_storage 116641 (not loaded) [CONFIG_KALLSYMS]
ffffffff8859dd00 fat 85873 (not loaded) [CONFIG_KALLSYMS]
ffffffff885aa300 vfat 46401 (not loaded) [CONFIG_KALLSYMS]
crash>
그래. 멀티패스 사용한다. HP 스토리지이며 lpfc 모듈이 올라가 있다.
자 lpfc 모듈등을 점검해 보자고 하자.
sosreport 에서 보여지는 module 정보에선 lpfc의 버젼은 8.2.0.33.3p 로 나온다.
이 모듈의 버그 혹은 업데이트 버젼이 있는지 확인해 보라고 해야한다.
일단 디스크가 떨어지는 버그는 버그질라에 보고되고 있다.
( https://bugzilla.redhat.com/show_bug.cgi?id=470610 )
그런데 큰일이 생겼다.
한참 분석중인상태에서 다시 리부팅이 이루어졌다.
보여진 메시지는 다음과 같다고 한다.
Dec 15 11:38:22 udb kernel: Bad page state in process ‘oracle’
Dec 15 11:38:22 udb kernel: page:ffff810126fed270 flags:0x0b20100000000008 mapping:ffff811038016598 mapcount:0 count:0 (Tainted: G B)
Dec 15 11:38:22 udb kernel: Trying to fix it up, but a reboot is needed
Dec 15 11:38:22 udb kernel: Backtrace:
Dec 15 11:38:22 udb kernel:
Dec 15 11:38:22 udb kernel: Call Trace:
Dec 15 11:38:22 udb kernel: [<ffffffff800c4570>] bad_page+0x69/0x91
Dec 15 11:38:22 udb kernel: [<ffffffff8000a76a>] get_page_from_freelist+0x262/0x3fa
Dec 15 11:38:22 udb kernel: [<ffffffff8000f10b>] __alloc_pages+0x65/0x2ce
Dec 15 11:38:22 udb kernel: [<ffffffff80010e8c>] do_wp_page+0x2fa/0x6b5
Dec 15 11:38:22 udb kernel: [<ffffffff80009406>] __handle_mm_fault+0xd9b/0xe5c
Dec 15 11:38:22 udb kernel: [<ffffffff80066b9a>] do_page_fault+0x4cb/0x830
Dec 15 11:38:22 udb kernel: [<ffffffff8001c8db>] vma_link+0xd0/0xfd
Dec 15 11:38:22 udb kernel: [<ffffffff8000de64>] do_mmap_pgoff+0x66c/0x7d7
Dec 15 11:38:22 udb kernel: [<ffffffff8002fd5e>] __up_write+0x27/0xf2
Dec 15 11:38:22 udb kernel: [<ffffffff8005dde9>] error_exit+0x0/0x84
Dec 15 11:38:22 udb kernel:
Dec 15 11:38:22 udb kernel: Bad page state in process ‘oracle’
Dec 15 11:38:22 udb kernel: page:ffff810126fed2a8 flags:0x0b2010000000002c mapping:0000000000000000 mapcount:0 count:1 (Tainted: G B)
Dec 15 11:38:22 udb kernel: Trying to fix it up, but a reboot is needed
Dec 15 11:38:22 udb kernel: Backtrace:
Dec 15 11:38:22 udb kernel:
Dec 15 11:38:22 udb kernel: Call Trace:
Dec 15 11:38:22 udb kernel: [<ffffffff800c4570>] bad_page+0x69/0x91
Dec 15 11:38:22 udb kernel: [<ffffffff8000a76a>] get_page_from_freelist+0x262/0x3fa
Dec 15 11:38:22 udb kernel: [<ffffffff8000f10b>] __alloc_pages+0x65/0x2ce
Dec 15 11:38:22 udb kernel: [<ffffffff80010e8c>] do_wp_page+0x2fa/0x6b5
Dec 15 11:38:22 udb kernel: [<ffffffff80009406>] __handle_mm_fault+0xd9b/0xe5c
Dec 15 11:38:22 udb kernel: [<ffffffff80066b9a>] do_page_fault+0x4cb/0x830
Dec 15 11:38:22 udb kernel: [<ffffffff8001c8db>] vma_link+0xd0/0xfd
Dec 15 11:38:22 udb kernel: [<ffffffff8000de64>] do_mmap_pgoff+0x66c/0x7d7
Dec 15 11:38:23 udb kernel: [<ffffffff8002fd5e>] __up_write+0x27/0xf2
Dec 15 11:38:23 udb kernel: [<ffffffff8005dde9>] error_exit+0x0/0x84
멋지다. 커널 개발자들도 눈을 씻고 봐야 한다는 Bad Page state 라는 에러가 보인다.
커널 개발의 수많은 부분중 메모리 관련된 mm 을 패칭하는 mm guy 들은 꼼꼼하기로 소문이 자자한데,
가장 많이 신경 쓰는 것이 Bad Page 부분이다.
lkml.org 를 보면 리누즈와 Gene 이란 사람의 bad page 관련 주고받는 내용이 있다.
( http://lkml.org/lkml/2009/8/1/66 http://lkml.org/lkml/2009/8/2/300 )
거기서 리누즈는 몇번의 테스트 요청 끝에 커널 버그가 아니라고 선언했다.
왜냐면 항상 동일 메모리 번지에 문제가 생겼기 때문이다. 그는 메모리 테스트를 해야하고,
Gene 은 메모리 테스트를 통해 메모리 문제를 확인 하였다. 이부분에 대한 메일링리스트도 있었던걸로
기억하는데 지금 찾아보니 없다. 8월 25일경이였는데…….
어쨋든 이 메시지를 받은 순간 고민하였으나,
바로 오늘만 다시 저 메시지와함께 세번의 리부팅이 있었다.
역시 거기서 나오는 Page 주소는 page:ffff810126fed270.
처음 호출시 tainted 라고 뿌려지며 오늘 보내준 메시지 역시 다음과 같다.
oracle@udb.kpetro.or.kr:/oracle>
Message from syslogd@ at Thu Dec 17 16:00:55 2009 …
udb kernel: Bad page state in process ‘tar’
Message from syslogd@ at Thu Dec 17 16:00:56 2009 …
udb kernel: page:ffff810137c95e70 flags:0x0ff0100000000008 mapping:ffff81104fedc850 mapcount:0 count:0 (Not tainted)
Message from syslogd@ at Thu Dec 17 16:00:58 2009 …
udb kernel: Trying to fix it up, but a reboot is needed
Message from syslogd@ at Thu Dec 17 16:01:00 2009 …
udb kernel: Backtrace:
Message from syslogd@ at Thu Dec 17 16:01:01 2009 …
udb kernel: Bad page state in process ‘tar’
Message from syslogd@ at Thu Dec 17 16:01:01 2009 …
udb kernel: page:ffff810137c95ea8 flags:0x0ff010000000082c mapping:0000000000000000 mapcount:0 count:2 (Tainted: G B)
Message from syslogd@ at Thu Dec 17 16:01:01 2009 …
udb kernel: Trying to fix it up, but a reboot is needed
Message from syslogd@ at Thu Dec 17 16:01:01 2009 …
udb kernel: Backtrace:
잘 봐라 역시 동일한 주소며 첫번째는 Tainted 가 없었지만 같은 buddy 에 있는 38번째 비트의 메모리번지에서
tainted 가 표시되고 있다.
이 경우는 분명히 메모리의 물리적 오류가 있다는 것을 알 수 있었다.
하지만 역시 Core 분석시 보여주던 부분도 있기 때문에 일단 memtest 를 해보고,
lpfc 관련 드라이버역시 최신 업데이트를 확인해 보라고 하였다.
디스크쪽과 메모리쪽의 중복된 문제들이 발견된 이상 하드웨어의 전반적인 점검또한 고객에게 권고 할 수 있을 것이다.
원래 처음엔 코어분석을 먼저 하지 않고 상기 Bad page 관련 메시지만 보았고,
백프로 메모리 테스트를 장담하였는데, Redhat 사의 커널 분석엔지니어역시 메모리 테스트를 동일하게 권고하였다.
Coredump Analysis 5#
상황#
VMware 에 올라가 있는 RHEL 4.7 Oracle Was 서버이다.
오전에 갑작스러운 셧다운이 일어났고, 덤프를 떴으나 덤프는 incompletement 라는 메시지와 함께
정상적으로 떨어지지 않았다.
이번엔 이럴 경우에 대해서 살펴 보기로 한다.
시스템 (OS) : RedHat Enterprise Linux 4 AS update 7
Kernel Ver. : 2.6.9-78.ELsmp
Machine : i686
Memory : 6G
분석과정#
일단 VMware 상에서의 넷덤프 및 디스크 덤프는 약간 정상적으로 작동하지 못하는 것 같다.
이 경우엔 Crash 툴을 통한 접근이 어렵다.
하지만 포기하지 말자. incompletement 코어를 가지고도 할 수 있는 일이 있으니,
그것은 바로 크래쉬 로그 뽑기이다.
strings 를 통해 문자열들을 뽑아보면 커널 크래쉬 로그가 남는다.
# ] strings vmcore-incomplement > core_strings
7.1G 정도 쌓여있던 코어파일에서 약 260메가 정도 되는 파일이 생성되었다.
이제 이 스트링파일을 열어보자. 이 용량역시 엄청나 VI 로 열기 버거울 수 도 있겠지만
어쩌겠냐…열어봐야지
앞에 막 들어가있는 가비지문자들은 전부버리자. 아마 케이스마다 다르겠지만,
난 앞의 약 5만줄을 날렸더니 그럭저럭 다음과 같은 볼만한 문자가 보이더라.
cpu_mask_to_apicid
cpu_mask_to_apicid
smp_call_function
wakeup_secondary_cpu
check_nmi_watchdog
timer_irq_works
unlock_ExtINT_logic
follow_hugetlb_page
load_balance
context_switch
interruptible_sleep_on
interruptible_sleep_on_timeout
sleep_on_timeout
migration_thread
__put_task_struct
자 좀 더 내리면 중간에 역시 마치 binary 스트링 뽑아냈을때 처럼 printf 포맷스트링들이 즐비해 있다.
다 무시하고 쭈~~~욱 내려가다보면 다음과 같은 눈에 확 들어오게 되는 문자열이 보이게 된다.
————-[ cut here ]————
많이 보던 문자 아닌가?
그렇다. crash 툴에서 찍어보던 log 를 나타내주는 문자열이였다.
자 이제 이 문자열을 검색해보자.
:/cut here
<4>————[ cut here ]————
<1>kernel BUG at kernel/exit.c:904!
<1>invalid operand: 0000 [#1]
<4>SMP
<4>Modules linked in: loop seos(U) eAC_mini(U) md5 ipv6 i2c_dev i2c_core vsock(U) vmmemctl(U) pvscsi(U) sunrpc cpufreq_powersave ide_dump scsi_dump diskdump zlib_deflate dm_mirror dm_mod button battery ac vmci(U) acpiphp pcnet32 mii floppy vmxnet(U) ext3 jbd ata_piix libata mptscsih mptsas mptspi mptscsi mptbase sd_mod scsi_mod
<4>CPU: 0
<4>EIP: 0060:[<c0124cc5>] Tainted: P VLI
<4>EFLAGS: 00010046 (2.6.9-78.ELsmp)
<4>EIP is at next_thread+0xc/0x3f
<4>eax: 00000000 ebx: ca340db0 ecx: 00717ff4 edx: dd4378f0
<4>esi: 000080aa edi: 00008551 ebp: b3a5c198 esp: e03d9f8c
<4>ds: 007b es: 007b ss: 0068
<4>Process emagent (pid: 27221, threadinfo=e03d9000 task=ca340db0)
<4>Stack: c012f536 00000246 00000000 b3a5c174 00000000 e03d9fa8 00000000 00000000
<4> c01265f5 b3a5c198 b7f98c34 b3a5c200 e03d9000 c02e09db b3a5c198 00717ff4
<4> b7f98c34 b7f98c34 b3a5c200 b3a5c1a8 0000002b c02e007b 0000007b 0000002b
위대한 탐험가들이여. 보이는가? 마치 crash 를 실행시켜 bt 나 log 를 찍었을 때와 동일한
EIP 와 콜 트레이스 및 스택의 위용이 느껴지는가?
emagent 프로세스에서 걸리는 저 문제는 명백히 예전에 있던 이슈였고,
Oracle 측에서 2.6.9-78.0.22 커널로 올리는것을 권고했었던 적이 있는 사이트였다.
업무담당자는 emagent 가 안올라갔다고 했었으나, sysreport 와 코어 스트링, 그리고
재부팅된 서버에 접속하여 확인 해 본 결과로는 emagent 가 떡! 하니 돌아가고 있었다.
녀석의 야욕을 빠르게 읽어내어 승자의 미소를 띄우며 담당자에게 보고가 가능했고,
담당자는 크게 만족하며 고개를 끄덕였다.
깨진 코어파일을 R사에 보내봤자, 완벽한 파일만 요구받을 뿐이라는 교훈을 명심하기 바란다.
Coredump Analysis 6#
상황#
이번엔 매우 난감한 경우였다. 무려 한달이 넘도록 길게 끌어오던 이슈였으니까…
역시 VMware 에 올라가 있는 서버이며, WAS + Java APP 가 돌아가는 시스템이다.
OS 는 올 10월 EOS 가 되는 RHEL3 이다.
이슈는 원래 Hugemem 에 작동 되던 시스템을 VMware 지원 문제로 인하여 SMP 로 돌린다는것… ( Ram 16G )
자. 일단 살펴보자
.
시스템 (OS) : RedHat Enterprise Linux 3 AS update 6 ( 커널은 3.9 커널 )
Kernel Ver. : 2.6.21-50.ELsmp
Machine : i686
Memory : 16G
분석과정#
문제는 실제 장애상황에서도 좀체로 덤프를 뜰수가 없었던 상황이였다.
결국 다시 장애상황 발생하여 sysrq 로 덤프를 떴다. 자 중요하다 sysrq 다
RHEL 3버젼의 경우 다음과 같이 crash 실행을 해야 한다.
crash /boot/vmlinux-2.4.21-50.ELsmp vmlinux-2.4.21-50.ELsmp.debug /vmcore/vmcore
KERNEL: /boot/vmlinux-2.4.21-50.ELsmp
DEBUGINFO: vmlinux-2.4.21-50.ELsmp.debug
DUMPFILE: /vmcore/vmcore
CPUS: 4
DATE: Tue Mar 2 00:10:38 2010
UPTIME: 20 days, 17:24:55
LOAD AVERAGE: 37.56, 37.62, 33.58
TASKS: 1679
NODENAME: pil*****.*****.co.kr
RELEASE: 2.4.21-50.ELsmp
VERSION: #1 SMP Tue May 8 17:18:29 EDT 2007
MACHINE: i686 (2664 Mhz)
MEMORY: 17 GB
PANIC: “Oops: 0002” (check log for details)
PID: 3444
COMMAND: “crond”
TASK: efbe8000
CPU: 3
STATE: TASK_RUNNING (SYSRQ)
STAE 를 보면 재밌게도 TASK_RUNNING (SYSRQ) 라고 써져 있는 것을 볼 수 있다.
시스템 행업상태는 아니지만 SYSRQ 로 덤프를 떴다는 의미이다.
늘 R 사에서 하듯 log 부터 찍어보자.
Linux version 2.4.21-50.ELsmp (brewbuilder@hs20-bc1-6.build.redhat.com) (gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-58))
#1 SMP Tue May 8 17:18:29 EDT 2007
********************************************************
* This system has more than 16 Gigabyte of memory. *
* It is recommended that you read the release notes *
* that accompany your copy of Red Hat Enterprise Linux *
* about the recommended kernel for such configurations *
********************************************************
오옹… 여기 경고가 떡 하니 뜬다. Hugemem 을 권장하라는 얘기이다.
16기가라고 했는데, 실상 보니 약간 더 넘게 설정되어 있어 17G 로 인식한다 서버에서는…
SysRq : Crashing the kernel by request
Unable to handle kernel NULL pointer dereference at virtual address 00000000
printing eip:
c01d1620
*pde = 1dff1001
*pte = 00000000
Oops: 0002
netconsole audit vsock vmci vmmemctl nfs lockd sunrpc vmxnet microcode ext3 jbd mptscsih mptbase diskdumplib sd_mod scsi_mod
CPU: 3
EIP: 0060:[<c01d1620>] Tainted: GF
EFLAGS: 00210086
EIP is at sysrq_handle_crash [kernel] 0x0 (2.4.21-50.ELsmp/i686)
eax: efbe9e58 ebx: c03b9ec0 ecx: 00000001 edx: c0388e98
esi: 00000063 edi: 00000006 ebp: 00000063 esp: efbe9d84
ds: 0068 es: 0068 ss: 0068
Process crond (pid: 3444, stackpage=efbe9000)
Stack: c01d1caa 00000063 efbe9e58 c04fe544 f7fe0000 f7fe0000 c04fe544 efbe9e58
c01d1c0d 00000063 efbe9e58 c04fe544 f7fe0000 0000002e 00000002 00000003
efbe9e58 c01cf74b 00000063 efbe9e58 c04fe544 f7fe0000 2e00004d 0000002e
Call Trace: [<c01d1caa>] __handle_sysrq_nolock [kernel] 0x7a (0xefbe9d84)
[<c01d1c0d>] handle_sysrq [kernel] 0x5d (0xefbe9da4)
[<c01cf74b>] handle_scancode [kernel] 0x2ab (0xefbe9dc8)
[<c01d092d>] handle_kbd_event [kernel] 0xbd (0xefbe9df0)
[<c01d094c>] keyboard_interrupt [kernel] 0x1c (0xefbe9e08)
[<c010ddb9>] handle_IRQ_event [kernel] 0x69 (0xefbe9e0c)
[<c010dff9>] do_IRQ [kernel] 0xb9 (0xefbe9e2c)
[<c010df40>] do_IRQ [kernel] 0x0 (0xefbe9e50)
[<c02b0324>] call_do_IRQ [kernel] 0x7 (0xefbe9e54)
[<c0158f8f>] .text.lock.vmscan [kernel] 0xb7 (0xefbe9e80)
[<c01575fb>] rebalance_dirty_zone [kernel] 0xab (0xefbe9eac)
[<c015a1a9>] __alloc_pages [kernel] 0x399 (0xefbe9ed4)
[<c015a26c>] __get_free_pages [kernel] 0x1c (0xefbe9f1c)
[<c0126b1f>] dup_task_struct [kernel] 0x5f (0xefbe9f20)
[<c01274c7>] copy_process [kernel] 0x87 (0xefbe9f34)
[<c012805f>] do_fork [kernel] 0x4f (0xefbe9f64)
[<c016fb2c>] sys_stat64 [kernel] 0x5c (0xefbe9f84)
[<c0109d49>] sys_clone [kernel] 0x49 (0xefbe9fa0)
[<c02b006f>] no_timing [kernel] 0x7 (0xefbe9fc0)
Code: c6 05 00 00 00 00 00 c3 90 8d b4 26 00 00 00 00 0f b6 54 24
CPU#0 is frozen.
CPU#1 is frozen.
CPU#2 is frozen.
CPU#3 is executing netdump.
< netdump activated – performing handshake with the server. >
자 재밌게 netdump 동작한 부분까지 나온다. crond 에서 걸려있다.
bt 를 걸어봐 봤자 crond 에 대한 것만 나올테니 이번엔 대체 왜 문제가 생겼는지 부터 보자.
핵심은 행업상태인줄 알고 있었다는것 ( 서버 무반응 ). 일단 프로세스부터 보자.
crash> last
[179069506] PID: 1096 TASK: d7304000 CPU: 0 COMMAND: “syslogd”
[179069505] PID: 1927 TASK: e7856000 CPU: 0 COMMAND: “java”
[179069505] PID: 1935 TASK: de4f2000 CPU: 0 COMMAND: “java”
[179069505] PID: 1939 TASK: f5b5c000 CPU: 0 COMMAND: “java”
[179069504] PID: 1100 TASK: d7308000 CPU: 2 COMMAND: “klogd”
[179069504] PID: 1270 TASK: f6fee000 CPU: 1 COMMAND: “python”
[179069504] PID: 1444 TASK: f6eb0000 CPU: 1 COMMAND: “vmware-guestd”
[179069504] PID: 1782 TASK: f6a20000 CPU: 2 COMMAND: “login”
[179069504] PID: 1902 TASK: db52e000 CPU: 0 COMMAND: “java”
[179069504] PID: 27189 TASK: defe4000 CPU: 0 COMMAND: “nohup”
[179069504] PID: 30763 TASK: dd5f8000 CPU: 2 COMMAND: “httpd”
[179069503] PID: 1460 TASK: f6e78000 CPU: 2 COMMAND: “sshd”
[179069503] PID: 2048 TASK: efdd2000 CPU: 0 COMMAND: “java”
[179069503] PID: 2260 TASK: f405c000 CPU: 1 COMMAND: “java”
[179069503] PID: 15783 TASK: ecbde000 CPU: 0 COMMAND: “tecad_logfile”
[179069503] PID: 24013 TASK: e8aa0000 CPU: 1 COMMAND: “java”
[179069503] PID: 30944 TASK: dd4a0000 CPU: 2 COMMAND: “httpd”
[179069502] PID: 6 TASK: f7fa0000 CPU: 3 COMMAND: “keventd”
[179069502] PID: 1852 TASK: e5526000 CPU: 3 COMMAND: “opmn”
[179069502] PID: 32156 TASK: f608e000 CPU: 3 COMMAND: “httpd”
[179069501] PID: 24026 TASK: e8b80000 CPU: 0 COMMAND: “java”
[179069501] PID: 30481 TASK: df774000 CPU: 0 COMMAND: “httpd”
[179069500] PID: 12 TASK: d703c000 CPU: 2 COMMAND: “kscand”
[179069500] PID: 1894 TASK: e72be000 CPU: 3 COMMAND: “java”
[179069500] PID: 1896 TASK: e71ca000 CPU: 2 COMMAND: “java”
[179069500] PID: 2314 TASK: de6b8000 CPU: 1 COMMAND: “java”
………….. 중략 …………….
[179069480] PID: 1799 TASK: f698a000 CPU: 3 COMMAND: “bash”
[179069478] PID: 1726 TASK: f6af2000 CPU: 3 COMMAND: “ovcd”
[179069468] PID: 1723 TASK: f6bea000 CPU: 0 COMMAND: “ovcd”
[179069464] PID: 24017 TASK: ec11c000 CPU: 3 COMMAND: “java”
[179069460] PID: 11 TASK: d703e000 CPU: 2 COMMAND: “kswapd”
[179069443] PID: 2043 TASK: ebad0000 CPU: 0 COMMAND: “java”
[179069442] PID: 1345 TASK: f6ed8000 CPU: 2 COMMAND: “vmmemctl”
[179069436] PID: 1932 TASK: ebf20000 CPU: 3 COMMAND: “java”
[179069434] PID: 2426 TASK: eac56000 CPU: 2 COMMAND: “java”
[179069433] PID: 24030 TASK: dc280000 CPU: 2 COMMAND: “java”
………….. 중략 …………….
[178831011] PID: 30867 TASK: efcc2000 CPU: 3 COMMAND: “java”
[178831002] PID: 31762 TASK: e6964000 CPU: 3 COMMAND: “java”
[178830993] PID: 0 TASK: d8ad4000 CPU: 2 COMMAND: “swapper”
[178830986] PID: 32013 TASK: dfe80000 CPU: 2 COMMAND: “java”
[178830972] PID: 0 TASK: c03f8000 CPU: 0 COMMAND: “swapper”
[178830969] PID: 0 TASK: d8ad6000 CPU: 1 COMMAND: “swapper”
[178830912] PID: 30585 TASK: eacd8000 CPU: 0 COMMAND: “java”
[178830907] PID: 30586 TASK: dc32c000 CPU: 0 COMMAND: “java”
[178830905] PID: 20559 TASK: e5dee000 CPU: 0 COMMAND: “java”
………….. 중략 …………….
[179067620] PID: 31240 TASK: ef326000 CPU: 3 COMMAND: “httpd”
[179067560] PID: 31210 TASK: f001e000 CPU: 0 COMMAND: “httpd”
[179067550] PID: 31205 TASK: d76a6000 CPU: 0 COMMAND: “httpd”
[179067533] PID: 31192 TASK: d76e0000 CPU: 3 COMMAND: “httpd”
[179067533] PID: 31194 TASK: d76bc000 CPU: 3 COMMAND: “httpd”
[179067533] PID: 31208 TASK: d76a0000 CPU: 1 COMMAND: “httpd”
[179067519] PID: 31189 TASK: d76e6000 CPU: 2 COMMAND: “httpd”
[179067517] PID: 31184 TASK: d76ee000 CPU: 0 COMMAND: “httpd”
[179067505] PID: 31186 TASK: ef16a000 CPU: 3 COMMAND: “httpd”
[179067493] PID: 31174 TASK: d76fc000 CPU: 2 COMMAND: “httpd”
[179067493] PID: 31177 TASK: d76f6000 CPU: 2 COMMAND: “httpd”
[179067492] PID: 31181 TASK: d87f6000 CPU: 0 COMMAND: “httpd”
[179067467] PID: 31171 TASK: ef2b2000 CPU: 3 COMMAND: “httpd”
[179067461] PID: 31168 TASK: ef2b8000 CPU: 2 COMMAND: “httpd”
[179067455] PID: 31164 TASK: ef2be000 CPU: 0 COMMAND: “httpd”
[179067449] PID: 31161 TASK: ef464000 CPU: 1 COMMAND: “httpd”
[179067442] PID: 31156 TASK: ef46e000 CPU: 3 COMMAND: “httpd”
뭐 TASK 가 1600개 넘어가니 짜증이 난다. 대략 kscand 와 kswapd 가 보인다.
음… 이건 뭐 메모리부족인가? 하여 결국 bt 를 찍어보기로 한다. 여기서는 crond 에 걸려 그것만 나오기때문에,
foreach bt 를 사용하여 전체를 잘 살펴봐야 한다. ( 눈빠진다..하지만 걱정마라 금방 원인이 추정되어 나온다. )
foreach kernel bt
PID: 0 TASK: c03f8000 CPU: 0 COMMAND: “swapper”
#0 [c03f9f90] schedule at c0124280
#1 [c03f9fd4] cpu_idle at c01091e9
PID: 0 TASK: d8ad6000 CPU: 1 COMMAND: “swapper”
#0 [d8ad7f6c] schedule at c0124280
#1 [d8ad7fb0] cpu_idle at c01091e9
PID: 0 TASK: d8ad4000 CPU: 2 COMMAND: “swapper”
#0 [d8ad5f6c] schedule at c0124280
#1 [d8ad5fb0] cpu_idle at c01091e9
PID: 0 TASK: d7036000 CPU: 3 COMMAND: “swapper”
……….. 중략 ………….
커널 프로세스 위주로 Backtrace 해봤다. swapper 가 동작하는것 외에 특별한 스택을 볼순 없었다.
다시 이제 user 영역을 찍어보자
crash> foreach user bt
………. 중략 ………….
PID: 1210 TASK: f7200000 CPU: 1 COMMAND: “python”
#0 [f7201ea0] schedule at c0124280
#1 [f7201ee4] schedule_timeout at c01356f0
#2 [f7201f1c] do_select at c017aab6
#3 [f7201f60] sys_select at c017af59
#4 [f7201fc0] system_call at c02b0068
EAX: 0000008e EBX: 00000000 ECX: 00000000 EDX: 00000000
DS: 002b ESI: 00000000 ES: 002b EDI: bf7e7720
SS: 002b ESP: bf7e76ec EBP: bf7e7748
CS: 0023 EIP: 00be2067 ERR: 0000008e EFLAGS: 00000246
………. 중략 ………….
PID: 30481 TASK: df774000 CPU: 0 COMMAND: “httpd”
#0 [df775c18] schedule at c0124280
#1 [df775c5c] schedule_timeout at c01356f0
#2 [df775c94] wait_on_page_timeout at c0149545
#3 [df775cf0] rebalance_laundry_zone at c0156db5
#4 [df775d24] __alloc_pages at c015a119
#5 [df775d6c] __get_free_pages at c015a267
#6 [df775d70] kmem_cache_grow at c0152cc4
#7 [df775d98] __kmem_cache_alloc at c0153b2a
#8 [df775db8] alloc_skb at c022ad2f
#9 [df775dd0] tcp_sendmsg at c0257760
#10 [df775e40] inet_sendmsg at c027a15f
#11 [df775e54] sock_sendmsg at c0226f05
#12 [df775e98] sys_sendto at c02281ae
#13 [df775f64] sys_send at c0228202
#14 [df775f80] sys_socketcall at c0228ac2
#15 [df775fc0] system_call at c02b0068
EAX: 00000066 EBX: 00000009 ECX: bfffe910 EDX: b6038fdc
DS: 002b ESI: 00000000 ES: 002b EDI: 00000000
SS: 002b ESP: bfffe908 EBP: bfffe938
CS: 0023 EIP: b75b7fce ERR: 00000066 EFLAGS: 00200293
………. 중략 ………….
자 전반적으로다가 의심스러운 스택들이 튀어나와있다.
#0 [df775c18] schedule at c0124280
#1 [df775c5c] schedule_timeout at c01356f0
#2 [df775c94] wait_on_page_timeout at c0149545
#3 [df775cf0] rebalance_laundry_zone at c0156db5
#4 [df775d24] __alloc_pages at c015a119
#5 [df775d6c] __get_free_pages at c015a267
#6 [df775d70] kmem_cache_grow at c0152cc4
#7 [df775d98] __kmem_cache_alloc at c0153b2a
바로 위의 것들인데, 왜 의심스러운거냐 하면, 바로 메모리 관련하여 작업을 하고 있다는 것이기 때문이다.
전반적으로 많은 프로세스들에 rebalance_laundry_zone 과 kmem_cache_grow 등이 보이는데
이것들이 하는것은 메모리 사용량이 많아, 할당 가능한 메모리가 존재 하는지 안하는지 확인하는 것들이다.
결과적으로 전반적인 메모리 부족을 뜻하는 것인데, 할당 가능한 page 가 있는지 없는지 살펴보는 과정에서
wait_on_page_timeout 이 발생하여 page 를 기다리고, schedule_timeout 이 되어 프로세스가 계속
대기하게 되는 것이다.
이것이 장애와 어떤 연관이 있냐 하면, RHEL 3 의 경우 2.4 커널을 사용하며, 2.4 커널에서는
기본적으로 budy 알고리즘 만을 사용하도록 되어 있다. ( 알고리즘 설명은 따로 LDP 에서 뒤져봐라 )
이것은 연속된 특정 page 영역을 계속 찾고 검색하게 되있고. 이것은 곧 오버헤드를 발생시키는 것이 된다.
즉 위 상황에서 OS ( 커널 ) 는 메모리 할당을 위해 재사용할 메모리를 검색하는데 집중하느라 외부에서는
Hang-up 상태로 의심할만한 반응이 없는 상태가 되는것이다.
좀 더 찾아보니 다음과 같은 것도 있었다.
PID: 32154 TASK: efde0000 CPU: 2 COMMAND: “httpd”
#0 [efde1c9c] smp_call_function_interrupt at c011cc4f
#1 [efde1ca4] call_call_function_interrupt at c02b0ca8
EAX: c03f4dd0 EBX: c16b348c ECX: c16b348c EDX: 00000000 EBP: c03acf00
DS: 0068 ESI: 00000000 ES: 0068 EDI: 00000000
CS: 0060 EIP: c0158f86 ERR: fffffffb EFLAGS: 00000282
#2 [efde1cd8] .text.lock.vmscan (via launder_page) at c0158f86
#3 [efde1cfc] rebalance_dirty_zone at c01575f6
#4 [efde1d24] __alloc_pages at c015a1a4
#5 [efde1d6c] __get_free_pages at c015a267
#6 [efde1d70] kmem_cache_grow at c0152cc4
#7 [efde1d98] __kmem_cache_alloc at c0153b2a
#8 [efde1db8] alloc_skb at c022ad2f
#9 [efde1dd0] tcp_sendmsg at c0257760
#10 [efde1e40] inet_sendmsg at c027a15f
#11 [efde1e54] sock_sendmsg at c0226f05
#12 [efde1e98] sys_sendto at c02281ae
#13 [efde1f64] sys_send at c0228202
#14 [efde1f80] sys_socketcall at c0228ac2
#15 [efde1fc0] system_call at c02b0068
EAX: 00000066 EBX: 00000009 ECX: bfffe910 EDX: b6038fdc
DS: 002b ESI: 00000000 ES: 002b EDI: 00000000
SS: 002b ESP: bfffe908 EBP: bfffe938
CS: 0023 EIP: b75b7fce ERR: 00000066 EFLAGS: 00200293
결국 위 httpd 프로세스는 메모리 확보를 하는 과정에 빠져있었다는 것인데,
아니 왜 이렇게 메모리를 많이써? 왜 할당을 안해? 스왑은 뭐한데? 라고 할수 있으므로 다시 좀 더 보자.
다음은 kmem 을 통해 메모리 정보들을 확인 해 보는 것이다. -f 는 프리 page 갯수를 나타낸다.
crash> kmem -f
NODE
0
ZONE NAME SIZE FREE MEM_MAP START_PADDR START_MAPNR
0 DMA 4096 2776 c100002c 0 0
AREA SIZE FREE_AREA_STRUCT BLOCKS PAGES
0 4k c03acdd8 2 2
1 8k c03acde4 1 2
2 16k c03acdf0 1 4
3 32k c03acdfc 0 0
4 64k c03ace08 1 16
5 128k c03ace14 0 0
6 256k c03ace20 1 64
7 512k c03ace2c 1 128
8 1024k c03ace38 0 0
9 2048k c03ace44 1 512
10 4096k c03ace50 2 2048
ZONE NAME SIZE FREE MEM_MAP START_PADDR START_MAPNR
1 Normal 225280 10372 c103c02c 1000000 4096
AREA SIZE FREE_AREA_STRUCT BLOCKS PAGES
0 4k c03ae0d8 10372 10372
1 8k c03ae0e4 0 0
2 16k c03ae0f0 0 0
3 32k c03ae0fc 0 0
4 64k c03ae108 0 0
5 128k c03ae114 0 0
6 256k c03ae120 0 0
7 512k c03ae12c 0 0
8 1024k c03ae138 0 0
9 2048k c03ae144 0 0
10 4096k c03ae150 0 0
ZONE NAME SIZE FREE MEM_MAP START_PADDR START_MAPNR
2 HighMem 4227072 841406 c1d2002c 38000000 229376
AREA SIZE FREE_AREA_STRUCT BLOCKS PAGES
0 4k c03af3d8 0 0
1 8k c03af3e4 1 2
2 16k c03af3f0 1 4
3 32k c03af3fc 1 8
4 64k c03af408 1 16
5 128k c03af414 1 32
6 256k c03af420 0 0
7 512k c03af42c 1 128
8 1024k c03af438 0 0
9 2048k c03af444 1 512
10 4096k c03af450 821 840704
nr_free_pages: 854554 (verified)
신기한가? 멀었다. 잘 보면 DMA 영역으로 16메가가 할당되어 있고,
Normal 즉 lowmem table ( kernel 영역 ) 에 4k 짜리 페이지 외에 다른 크기의 메모리 block 들은
하나도 존재하지 않은 상태다. 즉 다 할당해 주고 더이상 연속된 8k 이상 페이지를 갖고 있지 않다는 얘기이다.
crash> kmem -i
PAGES TOTAL PERCENTAGE
TOTAL MEM 4102986 15.7 GB —-
FREE 854554 3.3 GB 20% of TOTAL MEM
USED 3248432 12.4 GB 79% of TOTAL MEM
SHARED 789017 3 GB 19% of TOTAL MEM
BUFFERS 22633 88.4 MB 0% of TOTAL MEM
CACHED 2437875 9.3 GB 59% of TOTAL MEM
SLAB 93293 364.4 MB 2% of TOTAL MEM
TOTAL HIGH 3964912 15.1 GB 96% of TOTAL MEM
FREE HIGH 841406 3.2 GB 21% of TOTAL HIGH
TOTAL LOW 138074 539.4 MB 3% of TOTAL MEM
FREE LOW 13148 51.4 MB 9% of TOTAL LOW
kmem: swap_info[0].swap_map at f8878000 is unaccessible
자 SLAB 영역이 무려 364메가 이상이고, LOW 영역이 고작 539 정도에 51메가밖에 남아있지 않는다.
결과적으로 LOW 멤에서 메모리 관련 작업은 불가능한 상태라는 것이다.
자 그래, 그럼 SLAB 갯수가 얼마나 되는지 확인해 보자.
crash> kmem -s> slab.txt
CACHE NAME OBJSIZE ALLOCATED TOTAL SLABS SSIZE
c03ab900 kmem_cache 244 74 96 6 4k
f7592914 nfs_write_data 384 0 0 0 4k
f7592a08 nfs_read_data 384 0 0 0 4k
f7592afc nfs_page 128 0 0 0 4k
f7592bf0 ip_fib_hash 32 10 336 3 4k
d8982ce4 ext3_xattr 44 0 0 0 4k
f7592ce4 journal_head 48 196 22869 297 4k
f7592dd8 revoke_table 12 11 500 2 4k
f7592ecc revoke_record 32 0 1792 16 4k
d8982dd8 clip_arp_cache 256 0 0 0 4k
d8982ecc ip_mrt_cache 128 0 0 0 4k
d8a0b080 tcp_tw_bucket 128 0 25380 846 4k
d8a0b174 tcp_bind_bucket 32 627 2800 25 4k
d8a0b268 tcp_open_request 128 303 3150 105 4k
d8a0b35c inet_peer_cache 64 4 116 2 4k
d8a0b450 secpath_cache 128 0 0 0 4k
d8a0b544 xfrm_dst_cache 256 0 0 0 4k
d8a0b638 ip_dst_cache 256 252 4350 290 4k
d8a0b72c arp_cache 256 6 435 29 4k
d8a0b820 flow_cache 128 0 0 0 4k
d8a0b914 blkdev_requests 128 3072 4140 138 4k
d8a0ba08 kioctx 128 0 0 0 4k
d8a0bafc kiocb 128 0 0 0 4k
d8a0bbf0 dnotify_cache 20 0 0 0 4k
d8a0bce4 file_lock_cache 96 17 2920 73 4k
…….. 중략 ……….
뭐, 간단히 SLAB 이란 원래 Solaris 계열에서 나온 정책인데, 쉽게 메모리 할당 후 혹시 쓰일지 모른다는 생각에
바로 폐기하지 않고, 남겨둔다는 것이다.
결국 커널은 동일한 크기의 연속된 메모리 (page) 를 요청하는 경향이 있기 때문에,
잦은 호출을 줄이기 위해 캐쉬 영역에 SLAB 을 둔다는 것이다.
결국 CACHE 에 SLAB 이 많이 존재 하게 되면 ( budy 를 자주 호출하게 되면 ) 직접적인 메모리 엑세스 타임에는
매우 큰 손실을 주게 되는 것이다. ( 캐쉬안에 존제된 연속된 채워진 혹은 비어있는 동일 크기의 페이지이므로 )
다시 한번 SLAB 부분 확인해 보고 결론을 들어가 보자.
[root@localhost root]# grep -E “sock|tcp” slab.txt
d8a0b080 tcp_tw_bucket 128 0 25380 846 4k
d8a0b174 tcp_bind_bucket 32 627 2800 25 4k
d8a0b268 tcp_open_request 128 303 3150 105 4k
d8acfce4 sock 1408 1805 2402 1201 4k
결과적으로 위 장애는 lowmem 의 부족으로 lowmem 영역 확보를 위해 캐쉬되있는 메모리를 검색하고,
반환하며, 또한 새로 할당하기 위해 일련의 과정들을 격는 중이였다는 것이며,
( 그러나 실제 캐쉬에서 사용가능한 부분은 없어 Lowmem 확보에 어려움이 있었던 것으로 판단. )
httpd 및 java 프로세스는 TCP 통신을 하기 때문에 Lowmem 을 많이 사용하였을 것이라는 결론.
특히 .text.lock.vmscan 은 HTTP 에서만 발생하였다.
Hugemem 으로 간다면 모르겠지만 그럴 수 있는 상황이 아니므로 ( VMware not support Hugemem )
즉 위의 문제는 장애가 아닌 튜닝이나 부하분산에 촛점을 맞춰야 한다는 것이다.
아래는 R 사의 답변 요약이다.
실제 Cached 메모리 자체 및 사용량은 12G 에 불과하므로 메모리를 줄이는것이 오히려 메모리 확보과정에
오버헤드를 줄일 수 있다는 내용인데. 큰 의미는 없다고 보여 진다…. ㅡ.,ㅡ::
@ 결론
– 시스템에서 실행 중인 프로세스가 많으며 대부분의 프로세스들이 비슷한 동작 즉,
지속적으로 lowmem을 요구하고 있습니다.
(CPU 4개 중 3개에서 httpd 프로세스가 TCP 통신을 위해 lowmem에서 buffer를 요청하고 있었습니다.)
– 커널에서는 분주히 lowmem 메모리 확보를 위한 작업을 수행하고 있습니다. (lowmem 영역은 swap 될 수 없습니다.)
– 이 때문에 시스템의 반응 속도가 현저히 줄어드는 것(Hang 상태이거나 Crash된 것이 아님)이며,
다시 말하면 시스템이 수용할 수 있는 한계보다 높은 부하로 인해 동작이 원활히 이루어지지 않는 것 입니다.,
– 이는 정상적인 반응이고 Red Hat Enterprise Linux 또는 커널의 문제가 아닙니다.
– 특별한 이슈가 없는 한, 이 이슈는 시스템 문제가 아닌 성능 튜닝이나 부하 관리 차원에서
다뤄져야 할 것으로 판단됩니다.
@ 권고 사항
– 현재 조건에서는 시스템 로드를 줄여주는 방법밖에는 없습니다.
– 현재 시스템 메모리가 17GB으로 보여집니다. 16GB 이하로 줄이시기 바랍니다.
– 현재 상황에서는 16GB는 다 사용하지도 못하고 있으므로, 8GB 또는 12GB 정도로 줄여 lowmem에서
physical memory mapping에 사용되는 공간(mem_map[])을 줄일 수 있을 것으로 생각됩니다.
Coredump Analysis 7#
상황#
이미 예전에 한번 CPU timer interrupt 방식 문제로 이슈가 발생 되었던 시스템이다.
문제는 약 6개월만에 또다시 터졌다는건데…
시스템 (OS) : RedHat Enterprise Linux 4 AS update 5 ( 커널은 4.8 커널 )
Kernel Ver. : 2.6.9-89.ELsmp
Machine : x86_64
Memory : 8G
분석과정#
간단하게 코어 바로 열고 log 찍어보았다.
KERNEL: vmlinux-2.6.9-89.ELsmp.x86_64
DUMPFILE: var/crash/127.0.0.1-2010-05-11-09:51/vmcore
CPUS: 8
DATE: Tue May 11 09:51:17 2010
UPTIME: 205 days, 20:36:24
LOAD AVERAGE: 0.22, 0.13, 0.07
TASKS: 342
NODENAME: ******02
RELEASE: 2.6.9-89.ELsmp
VERSION: #1 SMP Mon Apr 20 10:33:05 EDT 2009
MACHINE: x86_64 (3169 Mhz)
MEMORY: 8 GB
PANIC: “Kernel panic – not syncing: nmi watchdog”
PID: 15652
COMMAND: “scopeux”
TASK: 1006b7de7f0 [THREAD_INFO: 1000eef4000]
CPU: 0
STATE: TASK_RUNNING (NMI)
crash >
로그 보자….
crash > log
warning: many lost ticks
Your time source seems to be instable or some driver is hogging interupts
rip __do_softirq+0x4d/0xd0
Falling back to HPET
NMI Watchdog detected LOCKUP, CPU=0, registers:
CPU 0
Modules linked in: snapapi26(U) i2c_dev i2c_core md5 ipv6 ide_dump scsi_dump diskdump zlib_deflate
dm_mirror dm_mod emcpvlumd(U) emcpxcrypt(U) emcpdm(U) emcpgpx(U) emcpmpx(U) emcp(U) button
battery ac ohci_hcd ehci_hcd tg3 e1000 bonding(U) sg ext3 jbd qla2300 aacraid qla2xxx scsi_transport_fc sd_mod scsi_mod
Pid: 15652, comm: scopeux Tainted: P 2.6.9-89.ELsmp
RIP: 0010:[<ffffffff80141400>] <ffffffff80141400>{do_timer+197}
RSP: 0018:ffffffff8046dce0 EFLAGS: 00000012
RAX: 000000000001e7fc RBX: 000000006b1833d6 RCX: 000000000001e7fc
RDX: 0000000000000000 RSI: 00000000000f41a8 RDI: ffffffff8046ddc8
RBP: 0000000072a55f4d R08: 0000000000000008 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000008 R12: 00000000d73c7987
R13: 0000000072a55f4b R14: ffffffff8046ddc8 R15: 000000000000c3f0
FS: 0000000000000000(0000) GS:ffffffff80504500(005b) knlGS:00000000f7d7c6c0
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000f7ad8000 CR3: 0000000000101000 CR4: 00000000000006e0
Process scopeux (pid: 15652, threadinfo 000001000eef4000, task 000001006b7de7f0)
Stack: 00000005241efada 0000000000000000 000000000000037d ffffffff801167ee
ffffffff8046dd60 ffffffff801340e4 0000000000000044 00000004b1799b8e
000000018046ddc8 0000000000000000
Call Trace:<IRQ> <ffffffff801167ee>{timer_interrupt+587} <ffffffff801340e4>{rebalance_tick+133}
<ffffffff80112ff6>{handle_IRQ_event+41} <ffffffff80113270>{do_IRQ+197}
<ffffffff801108c3>{ret_from_intr+0} <ffffffff8013d859>{__do_softirq+77}
<ffffffff8013d90d>{do_softirq+49} <ffffffff80110c85>{apic_timer_interrupt+133}
<EOI> <ffffffff801656ca>{s_show+515} <ffffffff801656ca>{s_show+515}
<ffffffff80199fae>{seq_read+445} <ffffffff8017c2ec>{vfs_read+207}
<ffffffff8017c548>{sys_read+69} <ffffffff801266fc>{sysenter_do_call+27}
Code: 81 e1 ff 0f 00 00 48 c1 f8 0c 48 89 0d 37 0a 36 00 48 01 c6
Kernel panic – not syncing: nmi watchdog
———– [cut here ] ——— [please bite here ] ———
Kernel BUG at panic:77
invalid operand: 0000 [1] SMP
CPU 0
Modules linked in: snapapi26(U) i2c_dev i2c_core md5 ipv6 ide_dump scsi_dump diskdump zlib_deflate
dm_mirror dm_mod emcpvlumd(U) emcpxcrypt(U) emcpdm(U) emcpgpx(U) emcpmpx(U) emcp(U) button
battery ac ohci_hcd ehci_hcd tg3 e1000 bonding(U) sg ext3 jbd qla2300 aacraid qla2xxx scsi_transport_fc sd_mod scsi_mod
Pid: 15652, comm: scopeux Tainted: P 2.6.9-89.ELsmp
RIP: 0010:[<ffffffff80138992>] <ffffffff80138992>{panic+211}
RSP: 0018:ffffffff80470ca8 EFLAGS: 00010082
RAX: 000000000000002c RBX: ffffffff803287ce RCX: 0000000000000046
RDX: 00000000000121c3 RSI: 0000000000000046 RDI: ffffffff803f6700
RBP: ffffffff80470e58 R08: 0000000000000002 R09: ffffffff803287ce
R10: 0000000000000000 R11: 0000ffff80411b20 R12: 0000000000000000
R13: 0000000072a55f4b R14: ffffffff8046ddc8 R15: 000000000000c3f0
FS: 0000000000000000(0000) GS:ffffffff80504500(005b) knlGS:00000000f7d7c6c0
CS: 0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000f7ad8000 CR3: 0000000000101000 CR4: 00000000000006e0
Process scopeux (pid: 15652, threadinfo 000001000eef4000, task 000001006b7de7f0)
Stack: 0000003000000008 ffffffff80470d88 ffffffff80470cc8 0000000000000013
0000000000000000 0000000000000046 0000000000012197 0000000000000046
0000000000000002 ffffffff8032af27
Call Trace:<ffffffff801118f4>{show_stack+241} <ffffffff80111a1e>{show_registers+277}
<ffffffff80111d25>{die_nmi+130} <ffffffff8011de1b>{nmi_watchdog_tick+276}
<ffffffff801125f6>{default_do_nmi+116} <ffffffff8011df05>{do_nmi+115}
<ffffffff80111203>{paranoid_exit+0} <ffffffff80141400>{do_timer+197}
<EOE> <IRQ> <ffffffff801167ee>{timer_interrupt+587}
<ffffffff801340e4>{rebalance_tick+133} <ffffffff80112ff6>{handle_IRQ_event+41}
<ffffffff80113270>{do_IRQ+197} <ffffffff801108c3>{ret_from_intr+0}
<ffffffff8013d859>{__do_softirq+77} <ffffffff8013d90d>{do_softirq+49}
<ffffffff80110c85>{apic_timer_interrupt+133} <EOI> <ffffffff801656ca>{s_show+515}
<ffffffff801656ca>{s_show+515} <ffffffff80199fae>{seq_read+445}
<ffffffff8017c2ec>{vfs_read+207} <ffffffff8017c548>{sys_read+69}
<ffffffff801266fc>{sysenter_do_call+27}
Code: 0f 0b 4e 8d 32 80 ff ff ff ff 4d 00 31 ff e8 2f bb fe ff 83
RIP <ffffffff80138992>{panic+211} RSP <ffffffff80470ca8>
이번 분석은 여기서 끝난다. 간단하게 로그에 나오듯이 TSC 를 기본 인터럽트 방식으로 사용하고 있는 Linux 에서
정상적으로 CPU time 을 인터럽트 하지 못했을 경우에는 HPET 라는 방식으로 자동 전환하여
CPU time 을 가져오려고 한다.
그런데 여기선 HPET 방식으로의 전환이 불가능 했고, 그로 인해 30초 이상의 CPU time 을 얻어오지 못함으로,
NMI_Watchdog 에서 커널 패닉으로 감지 한 것이다.
@결론
일전에 Redhat 에서 이 이슈가 있었을때 grub.conf 에 clocksource=hpet 을 커맨드라인에 넣어주어,
시작시부터 HPET 타이머를 이용하도록 하라는 권고가 있었고 적용 된 줄 알았었다…
하지만 clocksource 는 RHEL5 에서 적용 가능한 커맨드라인이였고, 보시다시피 이 시스템은 RHEL4
결국 고객에게 죄송하다는 말과 함께 clock=hpet 으로 수정..적용은 아직 안되고 있다 (리부팅해야하므로)
왜 RHEL5 에 적용되는걸 알려줘서 난감하게 만든겁니까~? ㅠㅠ
Coredump Analysis 8#
상황#
오랜만인데…SCTP 프로토콜 관련 문제로 이미 예전부터 RedHat 과 함께 공조하여 패치를 만들어오던
상황이다…패치적용된 테스트 커널을 만들어 레드햇에서 고객에 전달해 준 뒤, 사용 후 문제가 생기는지에대한
피드백을 요청하는등 작업이 이루어 졌었다가, 이번에 다시 커널패닉이 발생한 부분이다.
시스템 (OS) : RedHat Enterprise Linux 5
Kernel Ver. : 2.6.18-194.3.1.el5.it801213
Machine : x86_64
Memory : 12G
분석과정#
간단하게 코어 바로 열고 log 찍어보았다.
root@~]# crash /usr/lib/debug/lib/modules/2.6.18-194.3.1.el5/vmlinux vmcore20110128
………….생략…………….
KERNEL: /usr/lib/debug/lib/modules/2.6.18-194.3.1.el5/vmlinux
DUMPFILE: vmcore20110128
CPUS: 16
DATE: Fri Jan 28 10:39:19 2011
UPTIME: 35 days, 21:31:59
LOAD AVERAGE: 0.00, 0.09, 0.18
TASKS: 368
NODENAME: C**F2
RELEASE: 2.6.18-194.3.1.el5.it801213
VERSION: #1 SMP Mon May 31 04:01:01 EDT 2010
MACHINE: x86_64 (2666 Mhz)
MEMORY: 11.8 GB
PANIC: “Oops: 0000 [1] SMP ” (check log for details)
PID: 21246
COMMAND: “MUXD”
TASK: ffff81016fb5b100 [THREAD_INFO: ffff810123b10000]
CPU: 2
STATE: TASK_RUNNING (PANIC)
crash >
Backtrace 부터 찍어보자..
crash> bt
PID: 21246 TASK: ffff81016fb5b100 CPU: 2 COMMAND: “MUXD”
#0 [ffff810123b11a00] crash_kexec at ffffffff800ada85
#1 [ffff810123b11ac0] __die at ffffffff80065157
#2 [ffff810123b11b00] do_page_fault at ffffffff80066dd7
#3 [ffff810123b11bf0] error_exit at ffffffff8005dde9
[exception RIP: list_del+8]
RIP: ffffffff80153f77 RSP: ffff810123b11ca8 RFLAGS: 00010246
RAX: 0000000000200200 RBX: ffff81028b3220d0 RCX: ffff810123b11c88
RDX: ffff8100a4597380 RSI: ffff81031f03d222 RDI: ffff81028b3220d0
RBP: ffff8101fd7fe140 R8: ffff81019c550680 R9: ffff81028b322000
R10: ffff8103077f4880 R11: 00000000000000c8 R12: ffff8101fd7fe140
R13: ffff8100a4597380 R14: 0000000000000000 R15: ffff8100a4597380
ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
#4 [ffff810123b11cb0] sctp_association_free at ffffffff885133cd
#5 [ffff810123b11cd0] sctp_do_sm at ffffffff885106ae
#6 [ffff810123b11e30] sctp_primitive_ABORT at ffffffff8851f0e3
#7 [ffff810123b11e50] sctp_close at ffffffff8851de4c
#8 [ffff810123b11eb0] inet_release at ffffffff80263694
#9 [ffff810123b11ed0] sock_release at ffffffff800553a1
#10 [ffff810123b11ef0] sock_close at ffffffff80055592
#11 [ffff810123b11f00] __fput at ffffffff80012a96
#12 [ffff810123b11f40] filp_close at ffffffff80023b84
#13 [ffff810123b11f60] sys_close at ffffffff8001dfa6
#14 [ffff810123b11f80] tracesys at ffffffff8005d28d (via system_call)
RIP: 00000039a040d637 RSP: 00007fff077d4e80 RFLAGS: 00000206
RAX: ffffffffffffffda RBX: ffffffff8005d28d RCX: ffffffffffffffff
RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000004
RBP: 0000000000000000 R8: 00002ac6ddf1ceb0 R9: 000000399f919840
R10: 203a4e4e4f435349 R11: 0000000000000206 R12: 00007fff077d4ec0
R13: 00000000013e2360 R14: ffffffff8001dfa6 R15: ffff8100245eb680
ORIG_RAX: 0000000000000003 CS: 0033 SS: 002b
crash>
이번엔 로그 확인은 안할것이다. 어차피 모듈관련 로그만 떨어져있다…백트레이스와 비슷하게 나온다.
즉 Tainted 된 모듈은 없으며, 위에 BT 에서 보듯 SCTP 프로토콜의 Closing 후 Socket Descriptor 나 모듈을 해제할때
linked list 에서 엔트리제거과정에 오류가 발생하여 커널패닉이 떨어진 것 같다.
가장 마지막 스택들에 들어가있는 시스템콜을 보자면, sctp_association_free 인데, 이 이후에 list_del 에서
RIP 가 떨어져 있다… 즉 sctp_association_free 함수 호출 후, list 정리 함수에서 RIP 를 남기고 error_exit 를 호출한 것이므로,
list_del 에서 떨어진 패닉으로 확정 할 수 있겠다…
일단 RedHat bugzilla 에서 sctp 를 통한 검색을 해보았을땐 특별한 버그리포트를 찾을 수 없었다. ( 치사하게시리 ㅠㅠ )
분석 자체는 좀 많이 했는데 ( 대략 4시간가량 ) 실제 문서에서는 귀찮아서 간단하게 정리하겠다.
list_del+8 위치의 메모리번지에서 뻗은것이기 때문에, disassemble 을통해 살짝 살펴보자.
그래도 일단 list_del 이전의 호출되는 함수인 sctp_association_free 부분도 디스어셈코드를 보도록 하자 🙂
crash> dis sctp_association_free
0xffffffff885133ad <sctp_association_free>: push %r12
0xffffffff885133af <sctp_association_free+2>: push %rbp
0xffffffff885133b0 <sctp_association_free+3>: push %rbx
0xffffffff885133b1 <sctp_association_free+4>: cmpb $0x0,0x169d(%rdi)
0xffffffff885133b8 <sctp_association_free+11>: mov %rdi,%rbx
0xffffffff885133bb <sctp_association_free+14>: mov 0x20(%rdi),%rbp
0xffffffff885133bf <sctp_association_free+18>: jne 0xffffffff885133e4
0xffffffff885133c1 <sctp_association_free+20>: lea 0xd0(%rdi),%rdi
0xffffffff885133c8 <sctp_association_free+27>: callq 0xffffffff80153f6f <list_del>
0xffffffff885133cd <sctp_association_free+32>: cmpl $0x2,0x2d8(%rbp)
0xffffffff885133d4 <sctp_association_free+39>: jne 0xffffffff885133e4
0xffffffff885133d6 <sctp_association_free+41>: mov 0x2(%rbp),%al
0xffffffff885133d9 <sctp_association_free+44>: cmp $0xa,%al
0xffffffff885133db <sctp_association_free+46>: jne 0xffffffff885133e4
0xffffffff885133dd <sctp_association_free+48>: decw 0x14c(%rbp)
0xffffffff885133e4 <sctp_association_free+55>: lea 0x15c0(%rbx),%rdi
0xffffffff885133eb <sctp_association_free+62>: movb $0x1,0x1c(%rbx)
0xffffffff885133ef <sctp_association_free+66>: lea 0x1358(%rbx),%rbp
0xffffffff885133f6 <sctp_association_free+73>: xor %r12d,%r12d
0xffffffff885133f9 <sctp_association_free+76>: callq 0xffffffff8851861f <sctp_outq_free>
0xffffffff885133fe <sctp_association_free+81>: lea 0x1628(%rbx),%rdi
0xffffffff88513405 <sctp_association_free+88>: callq 0xffffffff8851961f <sctp_ulpq_free>
0xffffffff8851340a <sctp_association_free+93>: lea 0x28(%rbx),%rdi
0xffffffff8851340e <sctp_association_free+97>: callq 0xffffffff88517491 <sctp_inq_free>
0xffffffff88513413 <sctp_association_free+102>: mov 0x15b8(%rbx),%rdi
0xffffffff8851341a <sctp_association_free+109>: callq 0xffffffff88520900 <sctp_ssnmap_free>
0xffffffff8851341f <sctp_association_free+114>: lea 0xa8(%rbx),%rdi
0xffffffff88513426 <sctp_association_free+121>: callq 0xffffffff88519d06 <sctp_bind_addr_free>
0xffffffff8851342b <sctp_association_free+126>: cmpq $0x0,0x1358(%rbx,%r12,1)
0xffffffff88513434 <sctp_association_free+135>: je 0xffffffff8851344a
0xffffffff88513436 <sctp_association_free+137>: mov %rbp,%rdi
0xffffffff88513439 <sctp_association_free+140>: callq 0xffffffff8003228e <del_timer>
0xffffffff8851343e <sctp_association_free+145>: test %eax,%eax
0xffffffff88513440 <sctp_association_free+147>: je 0xffffffff8851344a
0xffffffff88513442 <sctp_association_free+149>: mov %rbx,%rdi
0xffffffff88513445 <sctp_association_free+152>: callq 0xffffffff8851255a <sctp_association_put>
0xffffffff8851344a <sctp_association_free+157>: add $0x30,%r12
0xffffffff8851344e <sctp_association_free+161>: add $0x30,%rbp
0xffffffff88513452 <sctp_association_free+165>: cmp $0x1e0,%r12
0xffffffff88513459 <sctp_association_free+172>: jne 0xffffffff8851342b
0xffffffff8851345b <sctp_association_free+174>: mov 0x1288(%rbx),%rdi
0xffffffff88513462 <sctp_association_free+181>: callq 0xffffffff8000b3de <kfree>
0xffffffff88513467 <sctp_association_free+186>: mov 0x148(%rbx),%rbp
0xffffffff8851346e <sctp_association_free+193>: mov 0x0(%rbp),%r12
0xffffffff88513472 <sctp_association_free+197>: jmp 0xffffffff8851348b
0xffffffff88513474 <sctp_association_free+199>: mov %rbp,%rdi
0xffffffff88513477 <sctp_association_free+202>: callq 0xffffffff80153f6f <list_del>
0xffffffff8851347c <sctp_association_free+207>: mov %rbp,%rdi
0xffffffff8851347f <sctp_association_free+210>: mov %r12,%rbp
0xffffffff88513482 <sctp_association_free+213>: callq 0xffffffff88513afe <sctp_transport_free>
0xffffffff88513487 <sctp_association_free+218>: mov (%r12),%r12
0xffffffff8851348b <sctp_association_free+222>: lea 0x148(%rbx),%rax
0xffffffff88513492 <sctp_association_free+229>: cmp %rax,%rbp
0xffffffff88513495 <sctp_association_free+232>: jne 0xffffffff88513474
0xffffffff88513497 <sctp_association_free+234>: mov 0x1680(%rbx),%rdi
0xffffffff8851349e <sctp_association_free+241>: movw $0x0,0x158(%rbx)
0xffffffff885134a7 <sctp_association_free+250>: test %rdi,%rdi
0xffffffff885134aa <sctp_association_free+253>: je 0xffffffff885134b1
0xffffffff885134ac <sctp_association_free+255>: callq 0xffffffff88514798 <sctp_chunk_free>
0xffffffff885134b1 <sctp_association_free+260>: mov 0x1678(%rbx),%rdi
0xffffffff885134b8 <sctp_association_free+267>: test %rdi,%rdi
0xffffffff885134bb <sctp_association_free+270>: je 0xffffffff885134c2
0xffffffff885134bd <sctp_association_free+272>: callq 0xffffffff88514798 <sctp_chunk_free>
0xffffffff885134c2 <sctp_association_free+277>: mov %rbx,%rdi
0xffffffff885134c5 <sctp_association_free+280>: pop %rbx
0xffffffff885134c6 <sctp_association_free+281>: pop %rbp
0xffffffff885134c7 <sctp_association_free+282>: pop %r12
0xffffffff885134c9 <sctp_association_free+284>: jmpq 0xffffffff8851255a
crash>
특별히 배드스테이터스라고 할만한 코드는 보이지 않는데… 좀 이상한게 list_del 부분이 두번이나 호출된다는 점이다…
이건 sctp 모듈의 코드를 봐야 할것 같으나, 이 문서에서 그부분은 숙제로 남겨놓겠다.
chunk_free 도 두번이나 하는걸 보면 어쩌면 Double Chunk Free 버그일수도 있겠는데………. 😛
( 사실 소스를 난 봤는데 sctp 쪽을 잘 몰라서 모르겠더라 )
자..그럼 이제 list_del 의 디스어셈코드를 확인 해 보자.
crash> dis ffffffff80153f77 10
0xffffffff80153f77 <list_del+8>: mov (%rax),%rdx
0xffffffff80153f7a <list_del+11>: cmp %rdi,%rdx
0xffffffff80153f7d <list_del+14>: je 0xffffffff80153f9a <list_del+43>
0xffffffff80153f7f <list_del+16>: mov %rdi,%rsi
0xffffffff80153f82 <list_del+19>: xor %eax,%eax
0xffffffff80153f84 <list_del+21>: mov $0xffffffff802bbae9,%rdi
0xffffffff80153f8b <list_del+28>: callq 0xffffffff800924f7 <printk>
0xffffffff80153f90 <list_del+33>: ud2a
0xffffffff80153f9a <list_del+43>: mov (%rbx),%rax
0xffffffff80153f9d <list_del+46>: mov 0x8(%rax),%rdx
0xffffffff80153fa1 <list_del+50>: cmp %rbx,%rdx
0xffffffff80153fa4 <list_del+53>: je 0xffffffff80153fc1 <list_del+82>
0xffffffff80153fa6 <list_del+55>: mov %rbx,%rsi
0xffffffff80153fa9 <list_del+58>: mov $0xffffffff802bbb37,%rdi
0xffffffff80153fb0 <list_del+65>: xor %eax,%eax
0xffffffff80153fb2 <list_del+67>: callq 0xffffffff800924f7 <printk>
0xffffffff80153fb7 <list_del+72>: ud2a
0xffffffff80153fc1 <list_del+82>: mov (%rbx),%rdx
0xffffffff80153fc4 <list_del+85>: mov 0x8(%rbx),%rax
0xffffffff80153fc8 <list_del+89>: mov %rax,0x8(%rdx)
0xffffffff80153fcc <list_del+93>: mov %rdx,(%rax)
0xffffffff80153fcf <list_del+96>: movq $0x200200,0x8(%rbx)
0xffffffff80153fd7 <list_del+104>: movq $0x100100,(%rbx)
0xffffffff80153fde <list_del+111>: pop %rbx
0xffffffff80153fdf <list_del+112>: retq
crash>
길게 볼 필요는 없다. 사실 list_del 의 함수호출주소는 0xffffffff80153f68 이지만, +8 되는 오프셋 주소에서 문제가 생긴것이니,
0xffffffff80153f77 에서 찍어본 것이다. ( 앞쪽은 void 함수선언영역부분이 다이다. )
참고로 단순하게 dis list_del 이라고 해도 쭈욱 나온다. 🙂
자..list+8 부분에서 뻗은걸 기억해라.
그 아래부터 rd 명령으로 쭉 뿌려보면 16진수와 Ascii 문자들이 뿌려지는데 의미없는 문자들이 대부분이다.
printk 부분 메모리 영역을 자꾸 찍어보면 의미가 있는 소스구문이 발견된다.
(printk 는 kernel 에 문자를 출력하는 시스템콜인거 설명해야되나 ㅡ.,ㅡ:: )
crash> rd 0xffffffff802bbb37 40
ffffffff802bbb37: 5f7473696c3e333c 72726f63206c6564 <3>list_del corr
ffffffff802bbb47: 202e6e6f69747075 72703e2d7478656e uption. next->pr
ffffffff802bbb57: 6c756f6873207665 2c70252065622064 ev should be %p,
ffffffff802bbb67: 7361772074756220 3e333c000a702520 but was %p..<3>
ffffffff802bbb77: 6464615f7473696c 74707572726f6320 list_add corrupt
ffffffff802bbb87: 78656e202e6e6f69 20766572703e2d74 ion. next->prev
ffffffff802bbb97: 6220646c756f6873 7562202c70252065 should be %p, bu
ffffffff802bbba7: 7025207361772074 73696c3e333c000a t was %p..<3>lis
ffffffff802bbbb7: 6f63206464615f74 6e6f697470757272 t_add corruption
ffffffff802bbbc7: 3e2d76657270202e 6f6873207478656e . prev->next sho
ffffffff802bbbd7: 2520656220646c75 7720747562202c70 uld be %p, but w
ffffffff802bbbe7: 6c000a7025207361 70616d6f692f6269 as %p..lib/iomap
ffffffff802bbbf7: 672f62696c00632e 2e636f6c6c616e65 .c.lib/genalloc.
ffffffff802bbc07: 696c61766e690063 6e61747369642064 c.invalid distan
ffffffff802bbc17: 66206f6f74206563 006b636162207261 ce too far back.
ffffffff802bbc27: 2064696c61766e69 65636e6174736964 invalid distance
ffffffff802bbc37: 6e690065646f6320 696c2064696c6176 code.invalid li
ffffffff802bbc47: 656c2f6c61726574 646f63206874676e teral/length cod
ffffffff802bbc57: 72726f636e690065 6461656820746365 e.incorrect head
ffffffff802bbc67: 6b63656863207265 6e776f6e6b6e7500 er check.unknown
자 잘보면 next->prev 의 구문등이 보일것이다.
list_del 의 소스를 확인해 보자. (소스위치등이랑 struct 등의 확인은 직접 해보아라 재밌다.. )
일단 list 라는 명령을 사용해 메모리상에서 list_del 함수의 Linked List 상태를 확인 할 수 있다.
crash> list list_del
ffffffff80153f6f
fb894808478b4853
list: invalid kernel virtual address: fb894808478b4853 type: “list entry”
crash> p list_del
list_del = $2 =
{void (struct list_head *)} 0xffffffff80153f6f <list_del>
crash> list list_del 0xffffffff80153f6f
list: read error: kernel virtual address: ffffffff002a7ede type: “first list entry”
crash> list list_head 0xffffffff80153f6f
list: invalid argument: list_head
crash> list -s list_head 0xffffffff80153f6f
ffffffff80153f6f
struct list_head {
next = 0xfb894808478b4853,
prev = 0x1b74fa3948108b48
}
fb894808478b4853
struct list_head Cannot access memory at address 0xfb894808478b4853
crash>
crash> gdb list list_del
56 * @entry: the element to delete from the list.
57 * Note: list_empty on entry does not return true after this, the entry is
58 * in an undefined state.
59 */
60 void list_del(struct list_head *entry)
61 {
62 if (unlikely(entry->prev->next != entry)) {
63 printk(KERN_ERR “list_del corruption. prev->next should be %p, but was %p\n”,
64 entry, entry->prev->next);
65 BUG();
crash>
crash> gdb list *0xffffffff80153f77
0xffffffff80153f77 is in list_del (lib/list_debug.c:62).
57 * Note: list_empty on entry does not return true after this, the entry is
58 * in an undefined state.
59 */
60 void list_del(struct list_head *entry)
61 {
62 if (unlikely(entry->prev->next != entry)) {
63 printk(KERN_ERR “list_del corruption. prev->next should be %p, but was %p\n”,
64 entry, entry->prev->next);
65 BUG();
66 }
crash>
짜잔~ 여기선 gdb 의 명령이 나오게 된다. crash 툴에서 gdb 명령을 추가호출하여 사용이 가능한데.
gdb 에서 소스코드를 보여주는 명령은 list 이다.
Linked List 상태를 보여주는 명령과 동일하므로 gdb 명령을 이용해야한다.. 🙂
gdb list list_del 을 하면 안타깝게도 10줄만 딸랑 보여준다.. 원래는 인자를 넣어서 몇줄씩 볼 수 있으나,
crash 에서 제공하는 gdb 는 인자를 안먹는다 샹샹바…어쨋든 대신 그러면 아까 list_del+8 이 가르치는 주소가 어떤소스인지
확인을 해보도록 한다.
주소를 입력하면 저렇게 몇재쭐의 코드를 가르키는 메모리주소인지 알려준다! 🙂
역시 커널버그일때의 코드를 가르키고있다.
간단히 설명하자면, list_head 스트럭쳐에 있는 entry 중 prev->next 영역이 엔트리에서 참조되지 않고 있는것 같을때
list 해제에 대한 버그임을 뿌려주라는 것이다.
* unlikely 는 커널 매크로로 (함수아님) True 가능성이 높은지, False 가능성이 높은지 러프하게 추정하여 동작 할 수 있게
하는 일종의 확률매크로라고 볼 수 있다. 즉 조건문에 대해서 false 가 떨어질 가능성이 높다면 이라는 조건분기라고 할 수 있다.
빨간색 표시된 부분중 첫번째인 메모리 접근이 불가능하다는 것을 보았을때, 메모리 해제과정에서 더블프리버그 혹은,
메모리 참조포인터를 잃어서 정상적인 링크드리스트 처리가 되지 않아 커널패닉이 떨어진 것으로 확정 할 수 있다.
자 여기까지 분석했으니 이제 남은건 모듈개발자 혹은 커널 개발자가 패치해줘야 하는것이겠지…..
너무 많은걸 바라진 말자..나에게.. 힘이들다… ㅠㅠ
레드햇 답변 올때까지 기다려 봐야지뭐… 언젠간 나도 내공을 충분히 쌓아 실제 문제가 되는 모듈코드도 찾아서 수정하고
할 수 있겠지!!!! 🙂
Coredump Analysis 9#
상황#
이번엔 페도라 14 사용중인 내 노트북에서 발생한 커널 패닉이다.
자세한 상황설명은 GFS 테스트를 위해 KVM 을 이용하여 RHEL 5 노드 2개를 생성 후, 노트북에 iscsi 바인딩데몬을 올렸고,
각 노드에서 이것을 활용 할 수 있게끔 iscsi initiator 를 설정하던중 발생한 패닉이다.
정확하게 노트북 (편의상 Host 라고 하겠다.) 에서 작동하는 iptables 에 3260 포트가 오픈되지 않아,
포트오픈 룰을 추가 후 iptables restart 명령을 내리자 갑자기 패닉되며 코어덤프를 떠버리던 상황이다.
시스템 (OS) : Fedora 14 ( Laughlin)
Kernel Ver. : 2.6.35.12-88.fc14
Machine : x86_64
Memory : 4G
분석과정#
KERNEL: /usr/lib/debug/lib/modules/2.6.35.12-88.fc14.x86_64/vmlinux
DUMPFILE: /var/crash/127.0.0.1-2011-04-21-19:37:30/vmcore
CPUS: 4
DATE: Thu Apr 21 19:37:24 2011
UPTIME: 02:32:32
LOAD AVERAGE: 0.26, 0.56, 0.85
TASKS: 509
NODENAME: Mirr
RELEASE: 2.6.35.12-88.fc14.x86_64
VERSION: #1 SMP Thu Mar 31 21:21:57 UTC 2011
MACHINE: x86_64 (2394 Mhz)
MEMORY: 3.8 GB
PANIC: “[ 9137.459831] Kernel panic – not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81417249”
PID: 8762
COMMAND: “qemu-kvm”
TASK: ffff88012e0f5d00 [THREAD_INFO: ffff88008ca78000]
CPU: 2
STATE: TASK_RUNNING (PANIC)
자.. 일단 여기서 보여주는 정보..매우 좋다.
PANIC 의 원인은 일단 PID 8762 를 할당받은 qemu-kvm 커맨드에서 kernel stack 이 잘못된 주소를 참조하여 stack-protector 가 동작해 싱크가 불가했다는 얘기이다.
어렵나? 일단 BT 찍어보자. 로그먼저 찍어보아도 좋다.
[ 9137.459831] Kernel panic – not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81417249
[ 9137.459836]
[ 9137.459846] Pid: 8762, comm: qemu-kvm Not tainted 2.6.35.12-88.fc14.x86_64 #1
[ 9137.459852] Call Trace:
[ 9137.459857] <IRQ> [<ffffffff81468e1f>] panic+0x8b/0x10d
[ 9137.459877] [<ffffffff81417249>] ? icmp_send+0x50a/0x51c
[ 9137.459885] [<ffffffff8104de59>] get_taint+0x0/0x12
[ 9137.459890] [<ffffffff81417249>] icmp_send+0x50a/0x51c
[ 9137.459899] [<ffffffff81039d8f>] ? __wake_up_common+0x4e/0x84
[ 9137.459908] [<ffffffff81053a38>] ? local_bh_enable+0xe/0x10
[ 9137.459916] [<ffffffff8142bcfd>] ? ipt_do_table+0x590/0x6e7
[ 9137.459930] [<ffffffffa046821d>] ? br_dev_queue_push_xmit+0x82/0x88 [bridge]
[ 9137.459943] [<ffffffffa046d27e>] ? br_nf_dev_queue_xmit+0x0/0x83 [bridge]
[ 9137.459954] [<ffffffffa046d2ff>] ? br_nf_dev_queue_xmit+0x81/0x83 [bridge]
[ 9137.459965] [<ffffffffa046d277>] ? NF_HOOK_THRESH+0x4b/0x52 [bridge]
[ 9137.459973] [<ffffffff811e2f7b>] ? selinux_ip_forward+0x60/0x1c5
[ 9137.459982] [<ffffffff8142d8d0>] ? iptable_filter_hook+0x5c/0x60
[ 9137.459989] [<ffffffff813e1b8d>] ? nf_iterate+0x46/0x89
[ 9137.460001] [<ffffffffa046d5a1>] ? br_nf_forward_finish+0x0/0xa9 [bridge]
[ 9137.460006] [<ffffffff813e1c3a>] ? nf_hook_slow+0x6a/0xd0
[ 9137.460017] [<ffffffffa046d5a1>] ? br_nf_forward_finish+0x0/0xa9 [bridge]
[ 9137.460029] [<ffffffffa046d5a1>] ? br_nf_forward_finish+0x0/0xa9 [bridge]
[ 9137.460040] [<ffffffffa046d26d>] ? NF_HOOK_THRESH+0x41/0x52 [bridge]
[ 9137.460051] [<ffffffffa046d46c>] ? nf_bridge_pull_encap_header+0x25/0x31 [bridge]
[ 9137.460063] [<ffffffffa046ded1>] ? br_nf_forward_ip+0x1e0/0x1f4 [bridge]
[ 9137.460069] [<ffffffff813e3c5c>] ? __nf_conntrack_find+0x8d/0xea
[ 9137.460078] [<ffffffff813e1b8d>] ? nf_iterate+0x46/0x89
[ 9137.460087] [<ffffffffa046827c>] ? br_forward_finish+0x0/0x25 [bridge]
[ 9137.460093] [<ffffffff813e1c3a>] ? nf_hook_slow+0x6a/0xd0
[ 9137.460101] [<ffffffffa046827c>] ? br_forward_finish+0x0/0x25 [bridge]
[ 9137.460111] [<ffffffffa046827c>] ? br_forward_finish+0x0/0x25 [bridge]
[ 9137.460119] [<ffffffffa0468269>] ? NF_HOOK.clone.2+0x46/0x59 [bridge]
[ 9137.460128] [<ffffffffa046833a>] ? __br_forward+0x73/0x75 [bridge]
[ 9137.460137] [<ffffffffa04683a9>] ? br_forward+0x3a/0x4d [bridge]
[ 9137.460146] [<ffffffffa046906e>] ? br_handle_frame_finish+0x155/0x1c7 [bridge]
[ 9137.460156] [<ffffffffa0468f19>] ? br_handle_frame_finish+0x0/0x1c7 [bridge]
[ 9137.460168] [<ffffffffa046d277>] ? NF_HOOK_THRESH+0x4b/0x52 [bridge]
[ 9137.460179] [<ffffffffa046d49d>] ? nf_bridge_push_encap_header+0x25/0x31 [bridge]
[ 9137.460191] [<ffffffffa046d908>] ? br_nf_pre_routing_finish+0x205/0x228 [bridge]
[ 9137.460197] [<ffffffff813e1c3a>] ? nf_hook_slow+0x6a/0xd0
[ 9137.460207] [<ffffffffa046d703>] ? br_nf_pre_routing_finish+0x0/0x228 [bridge]
[ 9137.460219] [<ffffffffa046d703>] ? br_nf_pre_routing_finish+0x0/0x228 [bridge]
[ 9137.460231] [<ffffffffa046d277>] ? NF_HOOK_THRESH+0x4b/0x52 [bridge]
[ 9137.460242] [<ffffffffa046d9c0>] ? setup_pre_routing+0x4b/0x76 [bridge]
[ 9137.460254] [<ffffffffa046e369>] ? br_nf_pre_routing+0x484/0x494 [bridge]
[ 9137.460259] [<ffffffff813e1b8d>] ? nf_iterate+0x46/0x89
[ 9137.460266] [<ffffffff81066a45>] ? autoremove_wake_function+0x16/0x39
[ 9137.460276] [<ffffffffa0468f19>] ? br_handle_frame_finish+0x0/0x1c7 [bridge]
[ 9137.460282] [<ffffffff813e1c3a>] ? nf_hook_slow+0x6a/0xd0
[ 9137.460291] [<ffffffffa0468f19>] ? br_handle_frame_finish+0x0/0x1c7 [bridge]
[ 9137.460299] [<ffffffff8103d102>] ? __wake_up+0x44/0x4d
[ 9137.460308] [<ffffffffa0468f19>] ? br_handle_frame_finish+0x0/0x1c7 [bridge]
[ 9137.460318] [<ffffffffa0468f07>] ? NF_HOOK.clone.3+0x46/0x58 [bridge]
[ 9137.460327] [<ffffffffa0469251>] ? br_handle_frame+0x171/0x18c [bridge]
[ 9137.460336] [<ffffffff813bedd0>] ? __netif_receive_skb+0x2cd/0x412
[ 9137.460344] [<ffffffff810a9d8d>] ? check_for_new_grace_period.clone.19+0x8b/0x97
[ 9137.460352] [<ffffffff813c0742>] ? process_backlog+0x87/0x15d
[ 9137.460371] [<ffffffff8106b8d8>] ? sched_clock_cpu+0x42/0xc6
[ 9137.460379] [<ffffffff813c08c4>] ? net_rx_action+0xac/0x1bb
[ 9137.460385] [<ffffffff8106b8d8>] ? sched_clock_cpu+0x42/0xc6
[ 9137.460393] [<ffffffff81053dc9>] ? __do_softirq+0xf0/0x1bf
[ 9137.460401] [<ffffffff8100abdc>] ? call_softirq+0x1c/0x30
[ 9137.460407] [<ffffffff8100abdc>] ? call_softirq+0x1c/0x30
[ 9137.460411] <EOI> [<ffffffff8100c338>] ? do_softirq+0x46/0x82
[ 9137.460423] [<ffffffff813bfced>] ? netif_rx_ni+0x26/0x2b
[ 9137.460431] [<ffffffffa005d888>] ? tun_get_user+0x3e0/0x421 [tun]
[ 9137.460439] [<ffffffffa005ded1>] ? tun_chr_aio_write+0x0/0x84 [tun]
[ 9137.460447] [<ffffffffa005df3a>] ? tun_chr_aio_write+0x69/0x84 [tun]
[ 9137.460456] [<ffffffff81117d22>] ? do_sync_readv_writev+0xc1/0x100
[ 9137.460464] [<ffffffff811e4452>] ? selinux_file_permission+0xa7/0xb9
[ 9137.460474] [<ffffffff811dce11>] ? security_file_permission+0x16/0x18
[ 9137.460481] [<ffffffff81117f78>] ? do_readv_writev+0xa7/0x127
[ 9137.460488] [<ffffffff81125194>] ? do_vfs_ioctl+0x468/0x49b
[ 9137.460495] [<ffffffff81118941>] ? fput+0x22/0x1ed
[ 9137.460502] [<ffffffff8111803d>] ? vfs_writev+0x45/0x47
[ 9137.460508] [<ffffffff81118160>] ? sys_writev+0x4a/0x93
[ 9137.460515] [<ffffffff81009cf2>] ? system_call_fastpath+0x16/0x1b
crash> bt
PID: 8762 TASK: ffff88012e0f5d00 CPU: 2 COMMAND: “qemu-kvm”
#0 [ffff88000e303400] machine_kexec at ffffffff81027dc3
#1 [ffff88000e303480] crash_kexec at ffffffff81084ffa
#2 [ffff88000e303550] panic at ffffffff81468e26
#3 [ffff88000e3035d0] icmp_send at ffffffff81417249
#4 [ffff88000e303790] local_bh_enable at ffffffff81053a38
#5 [ffff88000e3037d0] ipt_do_table at ffffffff8142bcfd
#6 [ffff88000e303920] iptable_filter_hook at ffffffff8142d8d0
#7 [ffff88000e303930] nf_iterate at ffffffff813e1b8d
#8 [ffff88000e303980] nf_hook_slow at ffffffff813e1c3a
#9 [ffff88000e3039f0] NF_HOOK_THRESH at ffffffffa046d26d
#10 [ffff88000e303a20] br_nf_forward_ip at ffffffffa046ded1
#11 [ffff88000e303a60] nf_iterate at ffffffff813e1b8d
#12 [ffff88000e303ab0] nf_hook_slow at ffffffff813e1c3a
#13 [ffff88000e303b20] NF_HOOK.clone.2 at ffffffffa0468269
#14 [ffff88000e303b50] __br_forward at ffffffffa046833a
#15 [ffff88000e303b70] br_forward at ffffffffa04683a9
#16 [ffff88000e303b80] br_handle_frame_finish at ffffffffa046906e
#17 [ffff88000e303bc0] NF_HOOK_THRESH at ffffffffa046d277
#18 [ffff88000e303bf0] br_nf_pre_routing_finish at ffffffffa046d908
#19 [ffff88000e303c90] NF_HOOK_THRESH at ffffffffa046d277
#20 [ffff88000e303cc0] br_nf_pre_routing at ffffffffa046e369
#21 [ffff88000e303d00] nf_iterate at ffffffff813e1b8d
#22 [ffff88000e303d50] nf_hook_slow at ffffffff813e1c3a
#23 [ffff88000e303dc0] NF_HOOK.clone.3 at ffffffffa0468f07
#24 [ffff88000e303df0] br_handle_frame at ffffffffa0469251
#25 [ffff88000e303e20] __netif_receive_skb at ffffffff813bedd0
#26 [ffff88000e303e80] process_backlog at ffffffff813c0742
#27 [ffff88000e303ee0] net_rx_action at ffffffff813c08c4
#28 [ffff88000e303f40] __do_softirq at ffffffff81053dc9
#29 [ffff88000e303fb0] call_softirq at ffffffff8100abdc
— <IRQ stack> —
#30 [ffff88008ca79c20] netif_rx at ffffffff813bfbce
#31 [ffff88008ca79c60] netif_rx_ni at ffffffff813bfced
#32 [ffff88008ca79c80] tun_get_user at ffffffffa005d888
#33 [ffff88008ca79d00] tun_chr_aio_write at ffffffffa005df3a
#34 [ffff88008ca79d40] do_sync_readv_writev at ffffffff81117d22
#35 [ffff88008ca79e50] do_readv_writev at ffffffff81117f78
#36 [ffff88008ca79f30] vfs_writev at ffffffff8111803d
#37 [ffff88008ca79f40] sys_writev at ffffffff81118160
#38 [ffff88008ca79f80] system_call_fastpath at ffffffff81009cf2
RIP: 00000034e04d8ab7 RSP: 00007fe3a75e6998 RFLAGS: 00010202
RAX: 0000000000000014 RBX: ffffffff81009cf2 RCX: 0000000001376e68
RDX: 0000000000000001 RSI: 00007fe3a75e6920 RDI: 000000000000002a
RBP: 0000000000000001 R8: 0000000000000000 R9: 0000000000000000
R10: 0000000001343630 R11: 0000000000000293 R12: 00007fe3a75e6920
R13: 0000000001343670 R14: 0000000101343670 R15: 0000000000000000
ORIG_RAX: 0000000000000014 CS: 0033 SS: 002b
젠장할 길다. 그러나 사실 크게 여러가지 볼 필요는 없다. 이미 Stack Protector 가 동작한 주소가 나오고 있기 때문이다.
보면 icmp_send 라는 함수부에서 동일한 메모리 번지를 할당받았다.
icmp 룰 을 재정의하는 과정에 ( iptable 재시작을 했으니 ) 서 어떤 오류로 잘못된 참조값이 들어갔다는 얘기일 테니까..
일단 버그를 찾아보자…icmp_send 를 키워드로 bugzilla 와 kernel.org 또한 lkml 과 구글에게 물어봤으나,
이들도 썩 맞는 케이스를 던져주고 있지 않았다.
혹시 정말 icmp 소스에 어떤 논리적 오류라도 있는건가? 하여 소스를 확인해 보기로 했다.
crash> gdb list *0xffffffff81417235
0xffffffff81417235 is in icmp_send (net/ipv4/icmp.c:649).
644 ende:
645 ip_rt_put(rt);
646 out_unlock:
647 icmp_xmit_unlock(sk);
648 out:;
649 }
650
651
652 /*
653 * Handle ICMP_DEST_UNREACH, ICMP_TIME_EXCEED, and ICMP_QUENCH.
지금 나타내는 메모리번지의 코드라인은 649… } 로 블럭이 닫히는 부분이다.
제길 이 소스보기로는 의미가 없다 왜냐하면 저 주소는 저 코드가 들어가는 부분에 대한 표시일 뿐인거였다.
어쨋든 icmp.c 의 icmp_send 함수에서 생기는 문제인건 다시 확실해 졌는데 뭔가 다시 얻어낼 힌트 없을까?
소스를 쭈욱 직접 열어서 보면…. icmp_send 코드내용중에
/* RFC says return as much as we can without exceeding 576 bytes. */
631
632 room = dst_mtu(&rt->u.dst);
633 if (room > 576)
crash> l
634 room = 576;
635 room -= sizeof(struct iphdr) + icmp_param.replyopts.optlen;
636 room -= sizeof(struct icmphdr);
637
638 icmp_param.data_len = skb_in->len – icmp_param.offset;
639 if (icmp_param.data_len > room)
640 icmp_param.data_len = room;
641 icmp_param.head_len = sizeof(struct icmphdr);
굵게 칠한 부분들이 눈에 띈다.. 어라 이거 MTU 값이 576 인부분에대한 처리인데??
좋다 거의 다 왔다. 아까부터 사실 스택에 들어있는 함수들을 볼때 신경쓰였던게 br 즉 브릿지 관련 함수들이였다.
네트워크 관련된 이야기인데, KVM 에서는 호스트머신과 Guest 머신간 통신에 설정되는 내부 브릿지는 MTU 를 576 으로 소통한다.
즉 커널버그인건데, 버그질라에서 안나와서 구글에게 물었더니 RHEL6 에 관련된 버그질라 내용을 떡하니 보여준다. ( kvm icmp 로 키워드 )
https://partner-bugzilla.redhat.com/show_bug.cgi?id=629590 젠장… partner 라고 붙는 주소다…라지만 공개되어있다.
여기의 설명에 따르면 다음과 같은 구조를 설명해 준다.
<Remote Machine>–<Host Machine>–<Bridge>–<Tun/Tap>–<KVM Guest>
1500 mtu 576 mtu 576 mtu 576 mtu 1500 mtu
재밌는건 소스코드를 비교해봤는데 패치가 이미 적용되어 있다.
혹시 몰라 lkml 을 뒤져본다.
http://lkml.org/lkml/2010/8/30/391
요로코롬 이번엔 ip_output.c 의 ip_fragment 함수에 대해 패치가 있다.
어…이건 적용이 안되어있다.
커밋된지 한참 된것같은데….뭐 일단 어찌됐든, KVM 에서 Host 와 Guest 간 브릿지 MTU 값에 대한 문제로 생긴 icmp 라우팅문제라는게 대략적 결론.
다른아저씨들처럼 아직 MTU 수정해서 테스트해보진 않았으나 (글작성후 할거임)
확실히 다시 해보니 동일한 내용으로 코어가 생성된다.
커널메일링에 있는대로 ip option 관련 패치좀 해보고 정상유무 확인해야겠다. 오래된건데 왜 적용을 안했을까… 흑..
