Skills/mY Technutz 2020. 4. 6. 16:35

Oracle Linux 7 의 RHCK 를 사용하는 고객인데, Crash dump 가 발생하여 분석을 요청했다.

그냥 넘어가려고 했는데 eBPF 를 사용중인 서버에서 발생한 이슈라 흥미를 갖고

한번 살펴보기로 했다.

재밌는건 위 bpftool 은 sosreport 를 수집할때 systemtab 에 의해 수행되는 명령이었다.

재현테스트를 테스트머신을 만들어 수행해 보았으나, 아무런 이상없이

정상적으로 수집되고, 값도 정상적이다.

또한 bpftool 명령이 설치되어 있지 않다면 sosreport 수행 시행되지 않는다.

현재 고객은 위에서 보다시피 seos 등 3rd party 모듈을 여럿 사용하고 있었고,

filesystem permission 등의 관리가 이루어지고 있었기 때문에,

보안모듈을 의심할 수 밖에 없는 상황이였다.

안타깝게도, eBPFOL/RHEL 7 에서 Technical Preview 로 제공되므로,

더 깊은 상태의 investigation 이나 패치는 제공되지 않는다.

보다 상위의 커널들 ( Kernel 4.x, UEK4/5 ) 에서는 security_ops 를 아예 제거했고,

기본적으로 보안체크를 거치지 않고 다른 방법으로 처리하고 있었기에

적용하기도 어려운 상태였다.

결국 임시방편으로 고객에게 3rd-party 솔루션에서 bpftool 를 사용하는지 확인 후,

사용하지 않고, 필요로 하지 않는다면,

해당 패키지를 삭제하고 사용하지 않도록 하라고 권고하였다.

해당 패키지 (bpftool) 삭제 후 현재까지 이상없이 잘 운영중으로 보인다.

** Notes : 사실 Herbert 나 Todd 등 유수한 개발자님들께서 Technical Preview 라 귀찮다고
             코어덤프 거들떠보지도 않으셔서 상당히 어렵게 확인함 ㅋ

posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply Favicon of https://cuzmall.com/스포츠-레저/조아캠프-캠핑테이블-120-전용.. BlogIcon 조아캠프

     

    2020.06.14 03:37

Skills/System 2020. 3. 23. 21:29

메모리의 사용량 그리고 메모리의 어느정도 사용시 Swap 이 발생하고

이 비율을 어떻게 조절하는지에 대한 인터넷사이트나 페이지, 문서는 상당히 많은데,

막상 다소 잘못된 내용들이 너무 넘쳐나는 것 같고, 제대로 짚어주는 사람은 아무도 없어

글을 급하게 쓰기 시작한다.

사람의 인체와 마찬가지로 컴퓨터의 CPU 와 메모리라는 것은 상당히 복잡한 영역이다.

따라서 단순한 계산으로 쉽게 계산할 수 있는 방법은 존재하지 않는다.

결국 그때 그때의 사용정도만 종합적으로 보여준는 것이 다들 알고 있는

Free, top, mpstat, vmstat 등 의 명령인 것이다.

그 값에 의심을 갖지 말고 그냥 좀 믿자 .. 뇌피셜이 많아질수록 꼰대가 된다..

다시한번 결론!

Swappiness 가 0 으로 설정되어 있다고 해서 스왑을 안쓴다는건 아니다. 명심하자.

* 읽으신분들이 쪼금 되서 급하게 추가 :
"Swappiness 를 그럼 언제 쓰란 말이냐"

** File-backed 관련 테스트를 위한 간단한 Python code.
( file 은 dd if=/dev/zero of={filename} bs=1024M count=XXX 로 생성 )

#!/usr/bin/env python

import sys
import os

if len(sys.argv) != 2:
    print "usage: %s <file-name>" % sys.argv[0]
    sys.exit()

pid = os.getpid()

f = open(sys.argv[1], "r")
size=f.read()

print ("File read test (%d) : %s read - %dM") % (pid, sys.argv[1], len(size)/1024**2)

while True:
    pass

테스트를 할때 여러조건으로 중복으로 실행하며 테스트 해보시면 좋다..
(난 귀찮아서 ㅠㅠ)

*** 관련 하여 회사 Mailing List 에서 커널개발팀 답변 :

Also we *very strongly recommend* not setting vm.swappiness=0. That can
result in some corner cases where the system has sputtering hang-ups
when it finally does have to swap for some reason.

Unless oswatcher is showing major %so/%si (swap-out/in) activity, it's
not having any impact on system performance, so if the underlying
question is about performance, you're probably looking at the wrong thing.

Swappiness 가 메모리를 더 적극적으로 활용하도록 하는 것은 맞지만,

Pinch 상황 즉, 시스템 부하가 높아지는 상황에서는 심각한 서비스 영속성 ( service continuty )

손상시키는 결과를 불러올 수 있다는 점을 경고하고 있다.


posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2020. 3. 19. 10:41

회사 자동로그인 시스템을 회사 내부 워킹데스크탑에서 파이떤을 이용해 돌리는데,

보안을 위한 APM 을 사용하므로, 부팅시 꼭 직접 오프라인으로 비밀번호를 넣어줘야 부팅이되어

전원문제나 윈도우즈 업그레이드 문제 등으로 리부팅이 되면,

OS 영역으로 넘어가지를 못해서 모든 나의 "사무실에 출근한척 하기"

프로젝트와 연관된 자동화 프로그램들이 먹통이 되버리는 문제가 있었다...

특히 최근 코로나-19 로 인해 회사를 장기간 못가는 상황에서,

종종 맥북으로 cronjob 을 임시로 돌리는데

자꾸 안돌아가버리는 바람에 찾아보니.. cronjob 은 legacy/deprectated 된거나 마찬가지라

launchdlaunchctl 을 이용하라고 하는것이였다...

그래서 간략하게 plist 를 작성하고 등록하는 것에 대해서 기록해 본다.

WorkingDirectory 를 설정 안해서, 내부적으로 돌아가는 모듈화된 스크립트들이

자꾸 에러나서 한동안 삽질좀 했다는...

여러가지 동작을 하는 작업을 만들고 싶다면,

아래 애플 개발자매뉴얼을 참조하면 응용하기에 쓸만하다.

Launchd 가이드에는 사용가능한 Keyword reference 및 Cookbook 이 제공되어 유용!!

Daemons and Services Programming Guide

Launchd Guide and Cookbook

근데 사실 이거 다 필요없이 앱스토어에서 그냥 launch 로 검색하면

GUI 로 된 다양한 Launchd 관련 도구들이 많다...

즉, 난 개삽질 ㅋㅋㅋㅋㅋ

끝.

posted by mirr

댓글을 달아 주세요

Skills/System 2020. 2. 5. 15:20

한국은 별로 이슈가 없는데,

글로벌에서는 Oracle Unbreakable Linux Network ( 이하 ULN ) 에서 제공하는 패키지관리를

미러링하여 내부에서 사용하는 환경이 많다.

이를 위해 오라클에서는 ULN 에 등록된 서버프로파일에 yum server 로 사용하는지 확인하여

해당 채널 패키지를 미러링하는 서비스도 제공하고 있는데, 간단하게 해당 방법을 알아보도록 하겠다.

1. Prerequisuites

 - Oracle Linux 6 (x86_64) or later
- linux.oracle.com 와 linux-update.oracle.com 에 http/https 접근이 가능해야 한다.
- 당연하게도 Oracle Linux CSI (customer support identifier).

- ULN site 에 등록된 Oracle SSO ID
- 메타데이터 생성을 위한 최소 2G 이상의 공간과 6G 이상의 RAM

- Package 들을 저장하기 위한 충분한 저장공간

- 끝

posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2019. 12. 14. 16:16

원래 pyKdump 관련해서는 작성한지 몇일 됐었는데, 귀찮아서 한번에 쓰는 중이다.

pyKdump 자체도 상당히 강력하고 도움이 되는 Extension 이지만,

실제 내가 자주 쓰는 명령은 dis 명령으로써, 리버스 분석 명령인데,

이를 더욱 더 쉽게 도와주는 pyKdumpExtension 이 있어 소개하고자 한다.

바로 레드햇에서 근무하시는 커널박사님이신 권성주님PyCrashext 이다.

https://github.com/sungju/pycrashext

설치는 간단하므로 역시 해당 위키페이지를 살펴보고 설치하면 된다.

정말 멋지지 않은가! 

본문 글에 반영된 색들은 실제로 해당 기능을 사용시 보여주는 색을 그대로 표현한것이다.

사실 본문에 설명한역시 능력자님께서 손수 만들어 주셨다는 점이다.

다만 소스코드 보여주는 역할등은 일부 시스템(파이선 영향인듯) 에서는

완벽하게 돌아가지 않는것 같다.

일단 edis 에 대해서 파이선 버젼을 떠나 어느 시스템에서든 정상적으로 수행할 수 있도록

아래와 같이 간단한 패치를 했다.
( 성주샘에게 메일도 보냈으나 반영될지는 모르겠다.. 안되도 그냥 이렇게 수정해 쓰자 ㅋㅋ)

Report 는 반영되었고, 아래와 같이 변경되었다.

---

diff --git a/edis.py b/edis.py
index 0178d09..36d6e3b 100644
--- a/edis.py
+++ b/edis.py
@@ -872,7 +872,7 @@ def edis():
     except:
         encode_url = ""

 

-    if encode_url != "":
+    if encode_url != None and encode_url != "":
         op.add_option("-n", "--noaction",
                       action="store_true",
                       dest="noaction",
@@ -908,7 +908,11 @@ def edis():
         show_callgraph(args[0], 0, o)
         sys.exit(0)

 

-    disasm(args[0], o, args, os.environ["PYKDUMPPATH"])
+    if len(args) != 0:
+        disasm(args[0], o, args, os.environ["PYKDUMPPATH"])
+    else:
+        print("ERROR> edis needs an address or a symbol\n",
+              "\ti.e) edis 0xffffffff81c76fca or edis hugetlb_init")

 

 if ( __name__ == '__main__’):

-----

일단 이것은 edis 뒤에 주소가 인자로 주어지지 않았을 경우 파이선 에러가 출력되는 것을

막고 주소를 넣어달라고 안내하는 것이며,

encode_url 이 Null 일 경우 noaction 옵션이 추가되고 해당 액션이 수행되어야 하는데,

제대로 체크가 되지 않아 보다 직관적으로 none 을 확인하도록 수정해 준 약소한 부분이다.

현재 코드트리가 제대로 출력되지 않는 문제는 아직 손보고 있다.

어찌됐든, 상당히 유용하고 도움이 엄청 되는 확장플러그인이므로,

가능하다면 앞으로 나도 pyKdumppyCrashext 의 향상에 이바지를 하고 싶다.

이제 정말..... 난 먹고살길이 막막해 진것 같다.

오늘을 마지막으로 더이상의 커널 덤프 분석 공유 글은 중단하려고 한다.

그동안 나름대로 잘 읽어봐준 분들께 감사의 인사를 드리고,

다른 더 좋은 주제로 글을 쓸 수 있도록 노력하겠다.

posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2019. 12. 13. 17:44

요즘 다시 혼자서 근무하다보니, 업무량이 훅 늘어나고

분석에 대해서는 반복적인 부분이 많이 발생하는데 그에 대한 시간은 여전히 동일하게 들어서

간편화 하는 방법이 없을까 해서 간단히 python 으로 crash utility 에 대한 extension 을 직접 만들고 있었는데,

하늘아래 새로운 것은 없듯이 역시나 이미 만들어져 있었다는 것을 발견하였다.

그것은 바로 mPyKdump 라는 crash extension 이다.

https://sourceforge.net/p/pykdump/wiki/Home/

일단 커널 코어덤프 분석을 위한 도구인 crash 툴은 C/Python 형태의 외부 스크립트를

내부에서 불러와 사용할 수 있다.

대부분 c 로 컴파일되어 모듈형태로 crash 툴이 실행된 후 로드하는 형태로 사용되는데

mPyKdump 는 파이선 기준으로 작성되어 내용을 수정하더라도 특별히 컴파일이 필요없이

바로바로 적용이 가능하다는 장점이 있었다.

해당 모듈을 이용하여 얼마나 간편하게 기존 삽질을 줄일 수 있는지 확인해보자.

(Host정보 삭제함)


여기까지 PyKdump 모듈의 기능에 대해서 살펴보았다.

이제 커널정보들도 상당히 공개되고 알려져 먹고살기 참 힘든 세상이 되었다.

추가 팁 : 자동으로 mPyKdump 모듈을 로드시키고 싶을 경우,

.crashrc 파일을 만들어 아래와 같이 넣어주면 실행시 자동 로드한다.

.crashrc 는 크래쉬 툴 명령명과 동일하게 만들어 주면 된다.
(.crash64rc 와 같이.)

# cat ~/.crash64rc
extend /usr/local/lib64/mpykdump64.so


posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2019. 5. 11. 00:21

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

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

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

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

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

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

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

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

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

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

끝.

posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2019. 4. 4. 23:19

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

      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' 카테고리의 다른 글

The effective crash-utility for vmcore analysis (PyKdump)  (0) 2019.12.13
kernel Dump Analysis #18  (0) 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
posted by mirr

댓글을 달아 주세요

Skills/Cloud Computing 2018. 11. 1. 03:36

간단히 요약하자면,

- 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



posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2018. 3. 29. 13:31

결국 같은 이슈였다.

내가 전에 올렸던 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 do because 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  (0) 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

댓글을 달아 주세요