::: Dragon's Tail :::

« 2019/10 »
일	월	화	수	목	금	토
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

Skills/mY Technutz 2019.05.11 00:21

kernel Dump Analysis #18

벌써 18번째 인가... 사실 더 있지만 귀찮아서 안하다 보니.. ㅋㅋ

이번엔 GPU/DRM 관련 ~~버그.. 상당히 따끈따근한 새 버그~~에 대해서 Digging 해 본다.

      KERNEL: /share/linuxrpm/vmlinux_repo/64/4.14.35-1818.3.3.el7uek.x86_64/vmlinux
    DUMPFILE: vmcore [PARTIAL DUMP]
        CPUS: 16
        DATE: Tue Apr 16 15:42:21 2019
      UPTIME: 6 days, 01:18:20
LOAD AVERAGE: 0.00, 0.00, 0.00
       TASKS: 330
    NODENAME: *********
     RELEASE: 4.14.35-1818.3.3.el7uek.x86_64
     VERSION: #2 SMP Mon Sep 24 14:45:01 PDT 2018
     MACHINE: x86_64 (3600 Mhz)
      MEMORY: 63.3 GB
       PANIC: "general protection fault: 0000 [#1] SMP PTI"
         PID: 14887
     COMMAND: "plymouthd"
        TASK: ffff994e9c1adc40 [THREAD_INFO: ffff994e9c1adc40]
         CPU: 2
       STATE: TASK_RUNNING (PANIC)

crash7latest> mod -s drm usr/lib/debug/lib/modules/4.14.35-1818.3.3.el7uek.x86_64/kernel/drivers/gpu/drm/drm.ko.debug
     MODULE       NAME                    SIZE OBJECT FILE
ffffffffc0306b00 drm                   385024 usr/lib/debug/lib/modules/4.14.35-1818.3.3.el7uek.x86_64/kernel/drivers/gpu/drm/drm.ko.debug

crash7latest> mod -s drm_kms_helper usr/lib/debug/lib/modules/4.14.35-1818.3.3.el7uek.x86_64/kernel/drivers/gpu/drm/drm_kms_helper.ko.debug
MODULE NAME SIZE OBJECT FILE
ffffffffc0600500 drm_kms_helper 163840 usr/lib/debug/lib/modules/4.14.35-1818.3.3.el7uek.x86_64/kernel/drivers/gpu/drm/drm_kms_helper.ko.debug

모듈을 불러와준다.

crash7latest> bt -l
PID: 14887 TASK: ffff994e9c1adc40 CPU: 2   COMMAND: "plymouthd"
#0 [ffffa5a8096e7908] machine_kexec at ffffffffbd066191
    /usr/src/debug/kernel-4.14.35/linux-4.14.35-1818.3.3.el7uek/arch/x86/kernel/machine_kexec_64.c: 342
#1 [ffffa5a8096e7968] __crash_kexec at ffffffffbd12f4c2
    /usr/src/debug/kernel-4.14.35/linux-4.14.35-1818.3.3.el7uek/kernel/kexec_core.c: 947
#2 [ffffa5a8096e7a38] crash_kexec at ffffffffbd13061c
    /usr/src/debug/kernel-4.14.35/linux-4.14.35-1818.3.3.el7uek/include/linux/compiler.h: 206
#3 [ffffa5a8096e7a58] oops_end at ffffffffbd03148a
    /usr/src/debug/kernel-4.14.35/linux-4.14.35-1818.3.3.el7uek/arch/x86/kernel/dumpstack.c: 278
#4 [ffffa5a8096e7a80] die at ffffffffbd031b42
    /usr/src/debug/kernel-4.14.35/linux-4.14.35-1818.3.3.el7uek/arch/x86/kernel/dumpstack.c: 357
#5 [ffffa5a8096e7ab0] do_general_protection at ffffffffbd02ec12
    /usr/src/debug/kernel-4.14.35/linux-4.14.35-1818.3.3.el7uek/arch/x86/kernel/traps.c: 561
#6 [ffffa5a8096e7ae0] general_protection at ffffffffbda0388c
    /usr/src/debug/kernel-4.14.35/linux-4.14.35-1818.3.3.el7uek/arch/x86/entry/entry_64.S: 1272
    [exception RIP: drm_helper_probe_single_connector_modes+188]
    RIP: ffffffffc05e80ac RSP: ffffa5a8096e7b98 RFLAGS: 00010203
    RAX: 00ffff994e98cb08 RBX: ffff994aa7c62088 RCX: 000000000000001e
    RDX: ffffa5a8096e7c08 RSI: ffffa5a8096e7c08 RDI: ffff994aa7c65240
    RBP: ffffa5a8096e7c50   R8: ffff994e9b493fc0   R9: 0000000000000001
    R10: 0000000000000001 R11: 00000000fffffff2 R12: ffff994aa7c65218
    R13: ffff994aa7c62028 R14: ffffffffc03321a0 R15: ffff994aa7c62000
    ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018
    /usr/src/debug/kernel-4.14.35/linux-4.14.35-1818.3.3.el7uek/drivers/gpu/drm/drm_probe_helper.c: 423
#7 [ffffa5a8096e7c58] drm_mode_getconnector at ffffffffc02db97e [drm]
    /usr/src/debug/kernel-4.14.35/linux-4.14.35-1818.3.3.el7uek/drivers/gpu/drm/drm_connector.c: 1321
#8 [ffffa5a8096e7d10] drm_ioctl_kernel at ffffffffc02c4dec [drm]
    /usr/src/debug/kernel-4.14.35/linux-4.14.35-1818.3.3.el7uek/drivers/gpu/drm/drm_ioctl.c: 741
#9 [ffffa5a8096e7d50] drm_ioctl at ffffffffc02c51e4 [drm]
    /usr/src/debug/kernel-4.14.35/linux-4.14.35-1818.3.3.el7uek/include/linux/uaccess.h: 155
#10 [ffffa5a8096e7e60] do_vfs_ioctl at ffffffffbd29263a
    /usr/src/debug/kernel-4.14.35/linux-4.14.35-1818.3.3.el7uek/fs/ioctl.c: 47
#11 [ffffa5a8096e7ee8] sys_ioctl at ffffffffbd292c09
    /usr/src/debug/kernel-4.14.35/linux-4.14.35-1818.3.3.el7uek/fs/ioctl.c: 701
#12 [ffffa5a8096e7f28] do_syscall_64 at ffffffffbd003949
    /usr/src/debug/kernel-4.14.35/linux-4.14.35-1818.3.3.el7uek/arch/x86/entry/common.c: 295
#13 [ffffa5a8096e7f50] entry_SYSCALL_64_after_hwframe at ffffffffbda00195
    /usr/src/debug/kernel-4.14.35/linux-4.14.35-1818.3.3.el7uek/arch/x86/entry/entry_64.S: 247
    RIP: 00007f3beba00997 RSP: 00007fffc950e968 RFLAGS: 00000246
    RAX: ffffffffffffffda RBX: 000055beb6890720 RCX: 00007f3beba00997
    RDX: 00007fffc950e9f0 RSI: 00000000c05064a7 RDI: 0000000000000009
    RBP: 00007fffc950e9f0   R8: 0000000000000000   R9: 0000000000000004
    R10: 0000000000000009 R11: 0000000000000246 R12: 00000000c05064a7
    R13: 0000000000000009 R14: 00007fffc950e9f0 R15: 0000000000000009
    ORIG_RAX: 0000000000000010 CS: 0033 SS: 002b
crash7latest>

drm_probe_helper.c 의 423 라인의 drm_helper_probe_single_connector_modes 함수가 호출되면서

갑작스럽게 Kernel Protection 이 동작하였음을 확인 할 수 있다.

라인을 확인해 보면,

421:    /* set all old modes to the stale state */
422:    list_for_each_entry(mode, &connector->modes, head)
423:     mode->status = MODE_STALE;

425:    old_status = connector->status;

Disassemble 을 해보자.

crash7latest> dis -rl drm_helper_probe_single_connector_modes+188

/usr/src/debug/kernel-4.14.35/linux-4.14.35-1818.3.3.el7uek/drivers/gpu/drm/drm_probe_helper.c: 419
0xffffffffc05e8098 <drm_helper_probe_single_connector_modes+168>:       test   %eax,%eax
0xffffffffc05e809a <drm_helper_probe_single_connector_modes+170>:       js     0xffffffffc05e8726 <drm_helper_probe_single_connector_modes+1846>
/usr/src/debug/kernel-4.14.35/linux-4.14.35-1818.3.3.el7uek/drivers/gpu/drm/drm_probe_helper.c: 422
0xffffffffc05e80a0 <drm_helper_probe_single_connector_modes+176>:       mov    0x88(%r15),%rax
0xffffffffc05e80a7 <drm_helper_probe_single_connector_modes+183>:       cmp    %rax,%rbx
0xffffffffc05e80aa <drm_helper_probe_single_connector_modes+186>:       je     0xffffffffc05e80bb <drm_helper_probe_single_connector_modes+203>
/usr/src/debug/kernel-4.14.35/linux-4.14.35-1818.3.3.el7uek/drivers/gpu/drm/drm_probe_helper.c: 423
0xffffffffc05e80ac <drm_helper_probe_single_connector_modes+188>:       movl   $0xfffffffd,0x50(%rax)

structure 를 확인해보자.

crash7latest> struct drm_device 0xffff994aa7c65240
struct drm_device {
legacy_dev_list = {
    next = 0xffffa5a8096e7c08,
    prev = 0xffffa5a8096e7c08
},
if_version = 0,
ref = {
    refcount = {
      refs = {
        counter = 0
      }
    }
},
dev = 0x0,
driver = 0x0,
dev_private = 0xffff994aa7c65268,
control = 0xffff994aa7c65268,
primary = 0x6000000,
render = 0xffff994e9f1976a1,
registered = false,
master = 0x6000000,

[[[ 중략 ]]]

crash7latest> struct drm_device ffff994aa7c62000
struct drm_device {
legacy_dev_list = {
    next = 0xffff994aa7c65000,
    prev = 0xffff994e9bc55800
},
if_version = 0,
ref = {
    refcount = {
      refs = {
        counter = 0
      }
    }
},
dev = 0xffff994aa7c652f8,
driver = 0xffff994aa7c652f8,
dev_private = 0xc0c0c0c00000001e,
control = 0xffff994aa7c62148,
primary = 0x5,
render = 0xffffffffc02d9da0 <drm_connector_free>,
registered = 192,
master = 0x0,
unplugged = {
    counter = 0
},
anon_inode = 0xffff994aa7c62060,
unique = 0xffff994aa7c62060 "` \306\247J\231\377\377` \306\247J\231\377\377",
struct_mutex = {
    owner = {
      counter = 4294967296
    },
    wait_lock = {
      {
        rlock = {
          raw_lock = {
            val = {
              counter = 1
            }
          }

이제 실제 라인에 있는 connector mode, status 의 내용들을 살펴볼 차례다.

crash7latest> struct drm_connector.modes 0xffff994aa7c65240
modes = {
next = 0x1,
prev = 0xffff994e9bc54d28
}

crash7latest> struct drm_display_mode.status ffff994aa7c62000
status = MODE_OK

crash7latest> rd 0xffff994aa7c65240
ffff994aa7c65240: ffffa5a8096e7c08 .|n.....

crash7latest> rd -a 0xffff994e9bf77c08 << Null

crash7latest> device 0xffff994e9bf77c08
struct device {
parent = 0xffff994aa7c65310,
p = 0xffff994aa7c65310,
kobj = {
    name = 0xe0e0e0e00000001d <Address 0xe0e0e0e00000001d out of bounds>,
    entry = {
      next = 0x0,
      prev = 0x0
    },
    parent = 0x0,
    kset = 0xffff994e9b493fb8,
    ktype = 0x1,
    sd = 0x1,
    kref = {
      refcount = {
        refs = {
          counter = -1480171520
        }
      }
    },
    state_initialized = 0,
    state_in_sysfs = 1,
    state_add_uevent_sent = 0,
    state_remove_uevent_sent = 1,
    uevent_suppress = 0
},
init_name = 0x0,

자, 대략 설명하자면.. DRM connector 의 mode 는 MODE_OK 로 정상적인 상태였고,

DRM 을 위한 device 에 대한 내용을 확인 결과 Out of Bound 로 표현되는

잘못된 주소를 참조하고 있다는 것을 알 수 있었다.

따라서 커널은 시스템 보호를 위해 protection 을 수행하게 되었고, 그로 인해 패닉이 발생한 것이다.

사실은 MODE_STALE 로 바뀌어야 했던 상황이며,

이는 drm 모듈이 이미 해제하고 사용하지 않아야 할 메모리 번지를 접근하여 재사용하려 했기 때문에 발생한 문제이다.

커널 4.14.35-1844.4.4 버젼 에 픽스가 포함되어있으므로,

해당 버젼 이상으로 업데이트를 해야 해결할 수 있다.

분석한지 한시간도 안되서 알려진 버그를 찾았다는게 개인적으로 나름 웃긴 부분이며,

물론 실제로 고객이 분석을 요청했을때, 이렇게 상세하게 지원 해주지는 않는다.

업무 특성상 사실, 솔루션만 제공하면 되니까 그러는 것도 있지만,

돈내고 받는 서비스라는 생각에 이해할 수 있는 기반도 없이 스터디를 요구하는 경우가 많아서이기도 하고..

(이전에 사과먹다만 회사 내부 커널개발자라는 놈이
아주 미친/미친듯이 질문을 한적이 있는데 답답해 미치는줄 알았었...)

블로그에 상세내용을 올리는 것은 분석에 대한 기법을 공유하기 위해서다.

끝.

저작자표시

'Skills > mY Technutz' 카테고리의 다른 글

kernel Dump Analysis #18 (1)	2019.05.11
Kernel Dump Analysis #17 (0)	2019.04.04
libfc: Update rport reference counting bug - 1368175 (0)	2018.03.29
Kernel Dump Analysis #16 (0)	2018.02.22
Kernel Dump Analysis #15 (0)	2018.02.19
Kernel Dump Analysis #14 (0)	2018.02.13

posted by mirr

Trackback 0 : Comment 1

댓글을 달아 주세요

Addr Edit/Del Reply 저승사자
너같은 범죄자 새끼가.
누구 비판할 입장은 아닌것 같다.
2019.06.03 12:34

Skills/mY Technutz 2019.04.04 23:19

Kernel Dump Analysis #17

재밌는 리턴코드가 발견되어서 간만에 좀 디깅을 해봤다.

      KERNEL: /share/linuxrpm/vmlinux_repo/64/3.10.0-693.el7.x86_64/vmlinux
    DUMPFILE: 127.0.0.1-2019-01-17-00_38_36.zip_extract/vmcore [PARTIAL DUMP]
        CPUS: 40
        DATE: Thu Jan 17 00:38:38 2019
      UPTIME: 39 days, 18:26:52
LOAD AVERAGE: 0.19, 0.20, 0.24
       TASKS: 1420
    NODENAME: **********
     RELEASE: 3.10.0-693.el7.x86_64
     VERSION: #1 SMP Wed Aug 2 06:49:08 PDT 2017
     MACHINE: x86_64 (2199 Mhz)
      MEMORY: 63.9 GB
       PANIC: "BUG: unable to handle kernel paging request at ffffffffc0500790"
         PID: 72639
     COMMAND: "kworker/15:0"
        TASK: ffff880dc2744f10 [THREAD_INFO: ffff881052fb8000]
         CPU: 15
       STATE: TASK_RUNNING (PANIC)

crash64> log

[ 37.351715] ip6_tables: (C) 2000-2006 Netfilter Core Team
[236233.529248] perf: interrupt took too long (2501 > 2500), lowering kernel.perf_event_max_sample_rate to 79000
[346636.325549] perf: interrupt took too long (3127 > 3126), lowering kernel.perf_event_max_sample_rate to 63000
[602033.211929] perf: interrupt took too long (3916 > 3908), lowering kernel.perf_event_max_sample_rate to 51000
[2952215.839114] perf: interrupt took too long (4941 > 4895), lowering kernel.perf_event_max_sample_rate to 40000
[3436125.331154] BUG: unable to handle kernel paging request at ffffffffc0500790
[3436125.331196] IP: [<ffffffffc0500790>] 0xffffffffc050078f
[3436125.331224] PGD 19f5067 PUD 19f7067 PMD 8598de067 PTE 0
[3436125.331251] Oops: 0010 [#1] SMP
[3436125.331270] Modules linked in: ip6table_filter ip6_tables sctp_diag sctp dccp_diag dccp tcp_diag udp_diag inet_diag unix_diag af_packet_diag netlink_diag binfmt_misc iptable_filter bonding sb_edac edac_core intel_powerclamp coretemp intel_rapl iosf_mbi kvm_intel kvm irqbypass ipmi_ssif crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd iTCO_wdt dcdbas iTCO_vendor_support mxm_wmi sg ipmi_si ipmi_devintf ipmi_msghandler pcspkr mei_me mei lpc_ich shpchp wmi acpi_power_meter ip_tables xfs libcrc32c sd_mod crc_t10dif crct10dif_generic mgag200 drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm ixgbe ahci crct10dif_pclmul crct10dif_common igb crc32c_intel libahci megaraid_sas libata mdio i2c_algo_bit ptp i2c_core pps_core dca dm_mirror dm_region_hash
[3436125.331620] dm_log dm_mod
[3436125.331629] CPU: 15 PID: 72639 Comm: kworker/15:0 Not tainted 3.10.0-693.el7.x86_64 #1
[3436125.331661] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.5.5 08/16/2017
[3436125.331721] Workqueue: xfs-cil/dm-3 xlog_cil_push_work [xfs]
[3436125.331746] task: ffff880dc2744f10 ti: ffff881052fb8000 task.ti: ffff881052fb8000
[3436125.331776] RIP: 0010:[<ffffffffc0500790>] [<ffffffffc0500790>] 0xffffffffc050078f
[3436125.331810] RSP: 0018:ffff881052fbbca0 EFLAGS: 00010286
[3436125.331832] RAX: ffffc90007396450 RBX: ffff88100ce8dc08 RCX: 0000000000000000
[3436125.331860] RDX: 0000000000000480 RSI: ffff880c9fbd7980 RDI: ffffc900073968d0
[3436125.331887] RBP: ffff881052fbbd38 R08: 0000000000000000 R09: ffffc90007396450
[3436125.331915] R10: 0000000000000480 R11: 0000000000018d8c R12: 0000000000000480
[3436125.331943] R13: 0000000000000033 R14: 0000000000000002 R15: ffff880c9fbd7000
[3436125.331971] FS: 0000000000000000(0000) GS:ffff88105dfc0000(0000) knlGS:0000000000000000
[3436125.332002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[3436125.332026] CR2: ffffffffc0500790 CR3: 000000067136f000 CR4: 00000000003407e0
[3436125.332053] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[3436125.332081] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[3436125.332113] Stack:
[3436125.332124] ffff880a3aa68010 0000000000000000 ffff88085522f400 000000000c041837
[3436125.332158] 0000000000018d8c 0000000000000480 ffff88085522f528 0000000000000000
[3436125.332192] 0000000000000480 ffff881000006244 ffff880c9fbd7038 0000625000000001
[3436125.332224] Call Trace:
[3436125.332254] [<ffffffffc04021d8>] xlog_cil_push+0x2a8/0x430 [xfs]
[3436125.332293] [<ffffffffc0402375>] xlog_cil_push_work+0x15/0x20 [xfs]
[3436125.332322] [<ffffffff810a881a>] process_one_work+0x17a/0x440
[3436125.332347] [<ffffffff810a9638>] worker_thread+0x278/0x3c0
[3436125.332371] [<ffffffff810a93c0>] ? manage_workers.isra.24+0x2a0/0x2a0
[3436125.332398] [<ffffffff810b098f>] kthread+0xcf/0xe0
[3436125.332420] [<ffffffff8108ddeb>] ? do_exit+0x6bb/0xa40
[3436125.332443] [<ffffffff810b08c0>] ? insert_kthread_work+0x40/0x40
[3436125.332470] [<ffffffff816b4f18>] ret_from_fork+0x58/0x90
[3436125.332493] [<ffffffff810b08c0>] ? insert_kthread_work+0x40/0x40
[3436125.332518] Code: Bad RIP value.
[3436125.332538] RIP [<ffffffffc0500790>] 0xffffffffc050078f
[3436125.332564] RSP <ffff881052fbbca0>
[3436125.332580] CR2: ffffffffc0500790

아쉽지만, 여기까지만 하고 다음에는 uek 와 관련된 내용으로 포스팅을 해야할것 같다.

내용을 볼수 없어서 비교가 불가하기때문이다 흑... 갑자기 용두사미가 된거같은데 뭐 내맴.

저작자표시

'Skills > mY Technutz' 카테고리의 다른 글

kernel Dump Analysis #18 (1)	2019.05.11
Kernel Dump Analysis #17 (0)	2019.04.04
libfc: Update rport reference counting bug - 1368175 (0)	2018.03.29
Kernel Dump Analysis #16 (0)	2018.02.22
Kernel Dump Analysis #15 (0)	2018.02.19
Kernel Dump Analysis #14 (0)	2018.02.13

posted by mirr

Trackback 0 : Comment 0

댓글을 달아 주세요

Skills/Cloud Computing 2018.11.01 03:36

2018 Oracle Open World - Cloud Generation 2

간단히 요약하자면,

- Global Network Security

망분리 및 Cloud network routing 뿐만 아니라 데이타 자체에 대한 보안을 지원하는것.

사실 별로 관심도 없다.

어차피 데이타센터 레벨 이야기나 마찬가지기 때문에....

역시 늘 똑같은 레퍼토리로 지속적인 LDC (Local DataCentre) 또는

HDC (Hub DataCentre) 구축에 박차를 가할거라고 '공약' 만 "공략" 한다.

- Machine Learning/AI protection

ML 을 통해 AI 를 이용하여 고객의 장애에 자동적/즉각적으로 대처하고

장애 요소를 사전 파악하여 장애가 발생하기 전에 사전 처리도

자동화하여 서비스 무중단을 지속적으로 제공하는것.

Pervasive AI : 구석구석 인공지등의 손길을 미치게하여 사람의 손길이 필요 없도록 하는 것.

이를 위한 미래지향적 형태 변화:

* Rules-Driven -> Model-Driven

* Manual -> Automatic

* Static -> Contextual

* User-Driven -> Machine-based recomendation and exceptions

저작자표시비영리변경금지

'Skills > Cloud Computing' 카테고리의 다른 글

2018 Oracle Open World - Cloud Generation 2 (0)	2018.11.01
VXbench 라는 툴을 아십니까~? (3)	2012.02.21
Swiss army knife 에 비견되는 BtrFS - 2부 (0)	2012.02.20
Swiss army knife 에 비견되는 BtrFS - 1부 (0)	2012.02.17
클라우드 시스템에서의 DBMS 방식 (2)	2011.03.30
그대들은 유칼립투스를 아는가? (0)	2009.12.23

posted by mirr

Trackback 0 : Comment 0

댓글을 달아 주세요

Skills/mY Technutz 2018.03.29 13:31

libfc: Update rport reference counting bug - 1368175

결국 같은 이슈였다.

내가 전에 올렸던 Kernel Dump Analysis #14 / #15 두개의 이슈..

결국 #15 와 #14 모두 동일한 rport reference count 관련 race condition bug 였다.

비록 양상이 다르긴 했지만 모두 Kref 를 감소시키며 0 으로 만드는 과정에서

Race condition 으로 인해 다른 메모리 값을 참조하게 되는 버그였다.

아래는 해당 버그에 대한 Patchwork (GIT) 링크 이다.

https://patchwork.kernel.org/patch/9132823/

대략 reference count 를 초기화 하는 과정에서 Mutex lock 을 걸어

Violation 을 방지하려고 했는데, 매 타임마다 Locking 을 하고 그 값을 대기하다보니

그 대기시간중에 다른 스레드가 해당 구조체에 엑세스 할 기회를 만들어주게 되어

결국 해당 값이 바뀌어 버리는 일이 생길 수 있다는 것이고, ( Race condition )

이 과정을 단순히 Remote port 에 대한 참조카운트를 추가하여

해당 값을 Lookup 할때 (디스크 제거시에만) 참조값을 줄이면 되기 때문에

디스크를 제거/검색 하는 과정에서 매번 디스크 뮤텍스를 걸 필요가 없게 수정한 이다.

개 빡치는것은, 내가 분명 두가지 모두 최종 Call trace 는 다르지만 모두 libfc 모듈에서

fc_lport / fc_rport 관련 구조체에 대한 Referencing 에서 나오는 이슈이므로

동일한 것같다고 이야기 했지만,

커널 개발팀에서 계속 "아니다, 다르다, 재현해서 다시 살펴봐야 한다" 라고 우기는 바람에

고객이 너무 빡쳐서 "그냥 다 때려쳐 씨밤, 너네 구려!" 이랬다는 것...

졸라 중요고객이라고 지랄들을 해대서,

어떻게 해야 할지 몰라 냅뒀더니 두달이 지난 지금에서야

We are unable to reproduce the crash in QA setup which is often hard to dobecause it is not possible to replicate customer environment in the lab. However, The two core dumps even though showed different symptoms, but the underlying root cause is the same, the kref count being zero.

Rajan provided the Ksplice patch and rpms which has the fix to address kref handling.

'응 그래, 재현이 졸라 안되서 미안하지만...그래도 동일 이슈맞는것 같아

우린 이미 앞선 패치를 통해 솔루션을 제공했어. 우린 잘했다고'

이지랄을 떨고 있다.

개발자들 일안하냐? 내가 호구로 보이냐? ㅎㅎㅎㅎㅎ 아몰랑!

저작자표시비영리변경금지

'Skills > mY Technutz' 카테고리의 다른 글

kernel Dump Analysis #18 (1)	2019.05.11
Kernel Dump Analysis #17 (0)	2019.04.04
libfc: Update rport reference counting bug - 1368175 (0)	2018.03.29
Kernel Dump Analysis #16 (0)	2018.02.22
Kernel Dump Analysis #15 (0)	2018.02.19
Kernel Dump Analysis #14 (0)	2018.02.13

posted by mirr

TAG Bug, Kernel, Linux, oracle, Patch

Trackback 0 : Comment 0

댓글을 달아 주세요

Skills/mY Technutz 2018.02.22 13:27

Kernel Dump Analysis #16

와.. 대박... 일이 엄청나게 들어와..

공격적으로 오라클 리눅스를 장사하면 내가 쓰일만한 일이 있긴 하구나 하면서도

일이 이렇게 많아지면 개빡쳐서 아무것도 하기 싫어지는 현자타임같은게 온다는..

무튼, 요즘 핫하게 밀려들어오는 업무량 덕에 코어분석 일도 숭풍숭풍 막 쳐 들어오는..

이번에는 레드햇 커널 즉, Oracle Linux 에서 Cmompatibility 를 위해 제공하는

Redhat Compatible Kernel ( RHCK ) 와 관련된 커널 덤프 분석을 해주시겠다.

Technical Preview 이기 때문에 해당 부분에 대한 코드는

ASSERTCMP(op->state, ==, FSCACHE_OP_ST_DEAD);

로 수정되는 식으로 상황을 정리하는 코드가 추가된 것 같다.
( 수정된 코드 다운받거나 찾기 귀찮다! 바쁘다. 점심안에 써야한다 글을. )

물론 픽스는 해당 fscache 모듈을 사용하지 않도록 하거나,

( cachefilesd 데몬을 Disable 한다. )

ELSA-2017-0307 또는 ELSA-2017-0817 ( RHSA-2017-0817 대응) 에서 권고하는

kernel-2.6.32-696.el6 이후의 최신 버젼으로 업그레이드 하거나

6.8 GA kernel-2.6.32-642.el6 이하 커널로 다운그레이드 하면 된다고

Redhat 에서 이야기 하는 것 같다.

사실 개인생각으로는 커널 업그레이드를 해봤자 동일할것 같긴 해서

구지 필요하지 않다면 Cachefilesd 를 Off 하는게 더 좋을것 같다고 생각된다.

mount option 에서 fsc 가 생겼는데 이게 없으면 자동으로 fscache 가 활성화 된다고 하는 것 같다.

레드햇 이슈라 명확하게 솔루션 코드가 확인되지 않는 상태라 잘 모르겠으나

분석 방법이랑 워크어라운드 기입되 있음 이미 난 충분히 세계를 위해 기여한거시다...

저작자표시비영리변경금지

'Skills > mY Technutz' 카테고리의 다른 글

Kernel Dump Analysis #17 (0)	2019.04.04
libfc: Update rport reference counting bug - 1368175 (0)	2018.03.29
Kernel Dump Analysis #16 (0)	2018.02.22
Kernel Dump Analysis #15 (0)	2018.02.19
Kernel Dump Analysis #14 (0)	2018.02.13
Kernel Crash dump Analysis - #13 (0)	2017.12.20

posted by mirr

TAG analysis, Crash, Debug, FSCACHE, Kernel, Linux, nfs, OL, oracle, redhat, RHCK, UEK, vmcore, 리눅스, 오라클, 오라클리눅스

Trackback 0 : Comment 0

댓글을 달아 주세요

<PREV NEXT> 1 2 3 4 ··· 104

::: Dragon's Tail :::

calendar

Tag

My Link

Category

Recent Post

Recent Comment

Recent Trackback

Archive

kernel Dump Analysis #18

'Skills > mY Technutz' 카테고리의 다른 글

Trackback :

댓글을 달아 주세요

Kernel Dump Analysis #17

'Skills > mY Technutz' 카테고리의 다른 글

Trackback :

댓글을 달아 주세요

2018 Oracle Open World - Cloud Generation 2

'Skills > Cloud Computing' 카테고리의 다른 글

Trackback :

댓글을 달아 주세요

libfc: Update rport reference counting bug - 1368175

'Skills > mY Technutz' 카테고리의 다른 글

Trackback :

댓글을 달아 주세요

Kernel Dump Analysis #16

'Skills > mY Technutz' 카테고리의 다른 글

Trackback :

댓글을 달아 주세요

::: Dragon's Tail :::

Search

calendar

Tag

My Link

Category

Recent Post

Recent Comment

Recent Trackback

Archive

kernel Dump Analysis #18

'Skills > mY Technutz' 카테고리의 다른 글

Trackback :

댓글을 달아 주세요

Kernel Dump Analysis #17

'Skills > mY Technutz' 카테고리의 다른 글

Trackback :

댓글을 달아 주세요

2018 Oracle Open World - Cloud Generation 2

'Skills > Cloud Computing' 카테고리의 다른 글

Trackback :

댓글을 달아 주세요

libfc: Update rport reference counting bug - 1368175

'Skills > mY Technutz' 카테고리의 다른 글

Trackback :

댓글을 달아 주세요

Kernel Dump Analysis #16

'Skills > mY Technutz' 카테고리의 다른 글

Trackback :

댓글을 달아 주세요