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  (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

댓글을 달아 주세요

Skills/mY Technutz 2018. 2. 22. 13:27

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

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

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

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

이번에는 레드햇 커널 즉, 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

댓글을 달아 주세요

Skills/mY Technutz 2018. 2. 19. 13:18

저번 14 에 이어진 내용이라고 볼 수 있다.

지난시간 왜 시스템 커널 분석에서 fc_stat, fc_lport 에 집중했는지 나오는 부분이다.

이전 게시글에서와 동일하게 ffff880103e67a00  를 참조하는 부분에서 문제가 발생하였다.

따라서 fc_lport 에 관련되어 메모리를 사용함에 있어, 이미 해제된 메모리를 재참조하거나,

메모리 corruption 조건이 발생되고 있다는 것을 의미한다.

역시 저번 게시글과 같이 해당 코드에 논리적 오류나 Race condition 발생 여부,

Used-after-freed 현상에 대해서 더 살펴봐야 하는 상태이지만,

코드 상 특별히 문제될만한 부분은 발견되지 않았다는 점이 현 문제의 가장 큰 난관이다.

지금은 개발팀에서 in-house 로 동일 환경을 구성 후 재현테스트를 하고 있는 중이다.

이는 장비에 대한 특성 ( 펌웨어 문제 또는 하드웨어 관련 된 정보의 괴리 ),

즉 하드웨어 문제를 배제할 수 없는 의심스러운 부분이 있다는 것을 의미한다.



posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2018. 2. 13. 23:40

이젠 뭐, 커널에 대한 덤프 분석이라기 보다는

CRASH tool 의 사용법과, 이슈에 따라서 분석을 진행하는 방법에 대한 Guide 가 되어가는 것 같다.

이전엔 주절주절 말을 많이한것 같았는데, 오늘은 주로 코드나 어셈의 흐름을 위주로 설명해 볼까 한다.

시스템이 갑작스럽게 코어와 함께 리붓되었단다.

참고로 현재 이슈는 다른 이슈와 연결되어 발생한 이슈로써,

아직 해결되지는 않은 이슈이며, fc_lport 의 값을 찾기 위한 이유에 대해서 밝히지 않고 있었다.

물론 이어지는 덤프분석이 또 있을 것이며, 거기서 이유가 밝혀질 것이다.

여기서 중요한 부분은 위의 로그에서 빨간색으로 표현한 두줄의 스택로그이다.

현재 의심되는 부분은 RBX 로 들어가는 메모리가 Corruption 되거나 used-after-freed 현상인데,

두줄의 로그를 보았을 경우 used-after-freed 가 되지 않을까 싶다.

이번 경우에는 확실히 used-after-freed 현상이 가장 가깝기 때문이다.

즉, 해제된 것을 다시 사용하거나, Double free race condition 등이 발생하고 있다는 것이다.

물론... 소스코드상에서는 아직 오류를 찾을 수 없는 상황이다.

보다 자세하고 큰 그림은 다음 분석을 통해 함께 그려보도록 하겠다.

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

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
커널이 지원하는 기능을 확인하는 습관.  (1) 2017.02.06
Kexec/Kdump 의 제약사항에 대해서  (4) 2016.01.14
posted by mirr

댓글을 달아 주세요

Skills/Linuxworld 2017. 4. 26. 04:02

나에게 흥미로운 내용이 또 한가지 있다면, 파일시스템 관련 즉, I/O 관련 이슈이다.

이것은 천상 System Engineer 인 나로써는, 성능에 가장 영향을 미치는 부분중,

튜닝이 가능한 부분을 살펴보게 되기 때문일 것이다.

기사 본문(아직 유료) : https://lwn.net/Articles/720675/

일주일뒤 확인하면 무료일듯...

--------

밑의 댓글들 중에는 Kyber 에 대한 벤치마크 결과가 있냐고 묻기도 하고,

그 결과로 8ms 에서 1ms 으로 줄였다는 메일링 내용도 있기도 하며,
( http://marc.info/?l=linux-block&m=148978871820916&w=2 )

이런 스케쥴러가 BTRFS 같이 별도의 내부적 IO scheduler 나 Thread procedure 를 갖는
환경에서 정상동작 할지 우려하기도 하며,

확실한건 아닌데, 성능이 더 좋게 잘 동작하는것 같다고 하는 답변도 달려있다.

언제나, 리눅스는 물론, 시스템에 대한 엔지니어링을 하면서 항상 땔 수 없고,

내려놓을 수 없는 부분이 바로 성능이라고 생각된다.

디스크 성능에 대한 이야기를 쓰면서,

한때, 가상화에 한참 심취했을때, Disk I/O 에 대한 스케쥴러를 Deadline 과 NOOP 으로 바꿔

상당한 이득을 경험했을 때의 기억이 새삼 떠올랐다.

그때 엄청 감동이였는데... ㅎㅎㅎ

아무튼 리눅스의 성능에 중요한 요소인, Memory Management 와

Disk I/O scheduler 에 대한 것은 언제나 놓지 않아야 한다고 본다.

일단 술한잔 마시고, 예정화랑 구지성 같은 몸매종결 연애인들 나오는 프로 하악대며 보다보니,

어느덧 네시다 ㅠㅠ 제길... 오늘 회사 못나갈듯...

놀러나가야 하는데 징징징....

*PS : 멀티큐 블록 레이어에 대한 참고기사 (공개)
*PS2 : BFQ 소개 , Kyber 소개


posted by mirr

댓글을 달아 주세요

Skills/Linuxworld 2017. 2. 26. 00:33

최근 한 2주정도를 계속 게임과 미드에 몰입하던 터라 흥미로운 기사가 몇개 있었음에도 불구하고

그냥 '에이 제껴 어차피 일주일단위로 공개되는데 구지 내가....' 라는 마인드로 넘겨버리고 있었는데...

오늘은 좀 무료한 감이 있더라..(금방 질리는 게임불감증 ㅠㅠ)

그래서 그냥 여러가지 외국 기사들 보며 맥주나 마시던 중 Cgroup 내용이 있어서 살짝 소개하려고 한다.

-----

우리나라의 기라성같은 은둔고수들중에 가장 유명해진(?)
Full time kernel hacker 인 허태준님께서 메인테이너로 개발하고 있는 CGroup 에 대한 내용이라서
내가 실전에서 사용한지 너무 오래되서 가물가물한 지식임에도 불구하고, 다루어 보았다.

현재 커널개발에 대해서 상당히 여러부분에 걸쳐
다양한 변화 및 움직임이 일어나고 있음을 알려주기 위해서이며,
우리나라에선 혁신이란 말을 유행처럼 쓰지만,
외래문화를 바탕으로 두고 있는 사람들- 그냥 외국인 - 의 경우,
정말 필요할 때 자신을 깨부숴 갈 의향을 알리며 사용한다는 말임을
이해해야 한다는 것을 말하고 싶다.

맥주가 다 떨어져서 자야겠.......

원문은 : https://lwn.net/Articles/715051/
- 일주일 뒤 무료공개.

** 엮인글들을 읽어가는 재미가 쏠쏠하다는 점...
*** 태준님 짱이라는...


posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2017. 2. 6. 19:01

가끔 커널소스를 받아 make config 또는 make menuconfig 를 해보면,

자신의 커널이 어떤 기능을 디폴트로 지원하고 있는지 확인 할 수 있다.

이렇게 보다 보면 커널 디버깅에 대한 기능들도 일부 얻을 수 있고,

어떤 기능들을 리눅스에서 지원하고 있는지  확인 할 수 있어 가끔 도움이 되곤 한다.

참고로 난 Memory debugging 을 좀 해볼게 있어 디버깅모드를 상당히 많이

Enable 시켜 Recompile 중이다. 특히 debugfs 와 sysfs, ftrace 의 기능들을 좀 더 추가했다.

( 사실 Perf 랑 DTrace 등을 이용해도 되는데 왜때문에? ㅠㅠ )

또한 사용된 리눅스 커널은 바닐라 커널이 아닌 오라클의 UEK2 커널이며,

호환성 등을 위해 Linux kernel 2.6.39 (Flesh-Eating Bats with Fangs) 와

3.0.60 sneaky weasel 을 믹스하여 개발된 커널로

컴파일되는 버젼은 2.6.39 로 컴파일된다.

이건 오라클 UEK2 의 최신 바닐라커널인 셈이다.


주 : 자주는 보지 말자 -_-

주2 : 원래 LWN 기사 관련 번역을 어제 작성하다가 다 날려먹어서 멘붕에 그냥 간단한걸로..

posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply 푸우

    좋은 정보 감사해요

    2017.02.06 20:40

Skills/Linuxworld 2017. 1. 8. 13:38


원문 : https://lwn.net/Articles/710545/

이번주 LWN 에서 내가 흥미로와 하는 내용중 하나인 메모리 관련 기사가 올라와 번역해 본다.


----

즉, 기존의 빠른 발전을 위해 여러가지 추가해 왔던 메모리 관리 관련 기능들을 예로 들면서,

25년이 넘은 만큼, 리눅스 개발 전반적으로 "더 나은 진화를 위한 한발 물러섬"

에 대한 내면적 리뷰가 필요한 시점임을 전달하고 싶었던 것이 아닐 까 싶다.

자세한 내용은 다음주 수요일 이후 공개가 되니 직접 살펴보기 바란다.

근데 이렇게 이야기 해주면 다들 알긴 아나? 좀 회의가 들어 요즘 -_-


posted by mirr

댓글을 달아 주세요

Skills/System 2014. 1. 6. 14:17

자 막간을 이용해 간만에 kernel core dump 분석 들어간다...

사실 요즘 대박대박 대박사건으로 여러 사이트에서 터지고 있는 문제라,

뭐 보안이 필요한 부분인것도 아니고, patch 가 어차피 나와있으므로
( kspice 를 이용한 hot fix 이긴 하지만..)

과감하게 공개해 본다....



현재 Fixed kernel 버젼은 V2.6.32-400.34.1 이며, 아직 QA/Release ready 이다.

어렵다.. 아무튼, 해당 패치는 나와 있는 상태이지만, 릴리즈 된 각 커널마다,
또한 장비상황등등 마다 재발 가능성은 언제든지 있는 부분이기 때문에,
최신 official released kernel 로 업데이트 한후, ksplice 를 통한
추가적인 hot fix 를 적용해야 한다는 점!


ksplice 를 이용하면 커널에 대한 official release 가 나와있지 않은 상태에서,
리붓 없이 수정된 kernel space 로 교체, 사용이 가능하다.. 쯔앙!


끝. 짧고 간단하며, 일이 있는 상태에서도 이정도 글은 뭐.. 가능하다 ㅠㅠ
비슷한 이슈 보이는 Oracle Linux UEK 커널 사용자는 업데이트 꼭 하도록 하자.


2012/01/01 - [Skills/mY Technutz] - Kernel Dump Analysis #10


posted by mirr

댓글을 달아 주세요

Skills/Linuxworld 2013. 7. 10. 14:09

원문 : https://lwn.net/Articles/557082/

연애질하느라 귀차니즘에 오랜만의 포스팅..

요즘 거의 두달에 한번쯤 포스팅하게 되는 것 같다.

각설하고, 이번주 LWN 위클리매거진의 커널 개발 섹션에서 태준님의 이름이

자꾸 보이는거 같아서 궁금해서 살펴보았더나 재밌는 내용이라 포스팅!!
(허태준 님은 순수 오리지날 국산 풀타임 커널 해커이시다!! 
아직도 삼성에계시는지 잘모르겠네 ㅡㅡ)

다름아닌, 열라 고자세로 일관하는 공룡같은 리눅스계의 갑(구글신)과,

리눅스 내부 프로젝트간의 갈등이랄까..

고 조나단아저씨는 기사를 끝맺었다....

무엇보다. 난 이 태준님이 너무 존경스러운데, 역시 Maintainer 의 역할은 단순히

소스를 고치고 리뷰하는 정도에 그치는 것이 아닌, 많은 오픈소스 사용자들과,

그에 따른 기업들, 경우에 따라서는 커널 내부의 프로젝트 팀들간의 커뮤니케이션도

조절해야 하는 막중한 임무를 띈 수장임을 알 수 있게 되어 감동받은 기사랄까..

또한 구글의 저 팀님의 발끈함이 더 즐거웠던 기사!

이 기사는 수요일.. 즉 오늘 공개되어있으...
나의 무식함을 탓할 사람은.. 언제든지 탓해주길 바란다.

급 작성하는거라 좀 어이없을듯 하다 ㅠㅠ

 ** 같이읽으면 좋을 글 :
2012/05/04 - [Skills/Linuxworld] - Linux Kernel 의 배관계층 ( Plumbing-Layer ) 이란??

'Skills > Linuxworld' 카테고리의 다른 글

Btrfs - Getteing started -2  (0) 2014.01.06
Introduce to Btrfs -1  (0) 2014.01.03
[LWN] When The kernel ABI has to change  (5) 2013.07.10
[LWN] LSFMM 2013 - Btrfs : "Are we there yet?"  (0) 2013.05.06
lockdep work available in user-space  (0) 2013.02.12
[LWN] Adding a Huge Zero Page  (0) 2012.10.21
posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply carcass12321@gmail.com

    안녕하세요 미르님 리눅스 커널덤프를 구글에서 검색하다
    찾아 뵙게 되었습니다
    커널패닉 덤프 분석에대해 관심이 많아서 검색을 하다보면 여러가지 사례가 많이 나오는데
    미르님이 쓰신글을 보아도 선수지식 부족으로 이해가 가질 않습니다
    관련 교육도 없는거 같고 혼자 공부해야하는데
    최소 미르님이 분석하신 내용을 이해하려면 어떤 부분의 지식이 있어야하는지 궁금합니다
    우선 전 aix엔지니어라 유닉스 리눅스 os는 친숙합니다
    커널덤프 분석을 하려면 C언어나 어셈블리어 그리고 커널을 따로 공부해야하는지요
    두서 없는 질문 죄송합니다

    2013.08.01 15:21
  2.  Addr  Edit/Del  Reply Favicon of http://seblog.mirr4u.com BlogIcon Mirr

    저도 관련대학도 안나오고, 선수지식두 없이 참 힘들었었습니다.
    기본적으로, 리눅스의 구성상, 씨언어가 기본인데, 씨언어로 막 뭐든 만들겠다 정도까진 아니어도 되고,
    씨언어의 흐름과, 커널 코드의 이해가 있으면 됍니다...
    솔직히, 프로그래밍은 너무 어렵습니다, 하지만, 적절히 제공되는 툴을 이영한 디버깅은 앞으로 각광 받는 분야가 될거라고, 장담합니다.
    도움되셨길 바랍니다.

    2013.08.04 11:13
  3.  Addr  Edit/Del  Reply carcass12321@gmail.com

    미르님 답변 감사합니다...
    혹시 어떤식으로 공부하셨는지 자세히 조언 괜찮을까요?
    관련 책이나 공부하신 순서등이 궁금합니다.
    저같은경우 우선 C언어등을 다시 공부하고 리눅스 커널 내부구조라는 책으로
    커널을 공부하려고 하는데 제가 생각하는 접근 방식이 맞는건지 궁금하네요
    미르님의 경우 어떤식으로 하셨는지 궁금합니다
    혹시 블로그에 적는것이 불편하시면 carcass12321@gmail.com로 메일한통 부탁드립니다
    ( _ _) 계속 염치없게 물어봐서 죄송합니다
    주변에 조언을 구할사람이 없어서 안면도 없는 분에게 불편을 끼치네요

    2013.08.04 12:37
    •  Addr  Edit/Del Favicon of https://seblog.mirr4u.com BlogIcon mirr

      안녕하세요, 사실 어떤식으로 공부했냐고 물으신다면 딱히 삽질했다고밖에 답을 못해드릴거같네요 -_-::
      책은 닥치는대로 많이 읽어봤는데, 실질적으로 책보다는 E-Book 이나 Wikidocs 같은 웹에서나 컴퓨터상에서 쉽게쉽게 찾아 볼 수 있는 것들이 더 유용했구요,
      커널의 내부를 지금 기초부터 파고드는것도 나쁘진 않지만,
      요즘은 너무 방대해지고 복잡해져서 중도포기가 더 많이 있더라구요..

      2013.08.22 13:13 신고
    •  Addr  Edit/Del Favicon of https://seblog.mirr4u.com BlogIcon mirr

      실질적으로 Linux Kernel 의 경우 각각의 분야 ( 메모리, 씨피유, 블럭, 디바이스모듈 등) 로 나뉘어 개발되고 있을정도이기 때문에,
      커널 하나라고만 말하면 답이 없는 상태입니다..
      중요한건, 어떤 분야에 대한 어떤식의 모습을 꿈꾸느냐인데, 정확하게 MM(Memorymanage) 의 해커가 되고싶다 라거나, CPU scheduling 에대해서 해커가 되고 싶다 등등의 목표가 있어야 합니다.
      저도 사실 공부중인상태이기때문에 이렇다할 로드맵은 당연히 없구요 -_-..
      Kernel Source 분석을 무턱대고 하는 것 보다는 kernel-document 의 내용들을 하나하나 살펴보시는 것이 더 좋다고 생각되네요.

      2013.08.22 13:17 신고