'오라클'에 해당되는 글 5건

  1. 2018.02.22 :: Kernel Dump Analysis #16
  2. 2018.02.19 :: Kernel Dump Analysis #15
  3. 2017.02.06 :: 커널이 지원하는 기능을 확인하는 습관. (1)
  4. 2016.11.18 :: Kernel Live patching issue.
  5. 2016.01.14 :: Kexec/Kdump 의 제약사항에 대해서 (4)
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 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 2016. 11. 18. 12:00

LWN 에 흥미로운 기사가 떠서 이야기 해 보기로 결정하였다.

http://lwn.net/Articles/706327/

기사에 대한 간략한 요약과 필요하다 생각되는 부분에 대한 개인적 설명

** Notes : Notes 나 괄호 형태의 글은 본인의 생각 및 의견을 나타냄.

기사명 : Topics in live kernel patching

Kernel Mainline 에서 Live patching 에 대한 기능을 추가하는 작업은 여러해 동안 이루어져 왔고, 마침네 4.0 커널에 기본적인 Live patching support 기능을 추가하여 배포하게 되었다.

문제는 이 Live patching 에 대한 Validation 매카니즘을 어떻게 구현하는 것이 옳을까에 대한 문제에서 시작된다.

이번 Linux Plumber Conference 2016 에서 해당 내용을 주제로 토론하였다.

이 글은 토론의 내용을 요약하거나 정리해서 알려주는 기사가 아니라, 라이브패치를 개발하는 개발자들이 나아가야 하는 방향과 해결해야 하는 과제, 극복과정 등을 중점으로 작성되었다.

---------

여기까지가 Corbet 의 기사를 설명한 부분이다.

아무래도 스크롤의 압박이 강하고, 복잡한 부분도 많지만, 사실상 상당히 간단히 설명한 부분이며, 해석에 오역이 있을 수 도 있다고 생각하지만,

상당히 잘 요약했다고 생각한다. (나말이야...난 잘 한거같다고... ㅎㅎㅎ)

약간 미국식 스크립트(코멘터리) 형태로 표현하긴 했는데 재미없을수도 있겠다..

그냥.. 패스... 귀찮아.. 일주일 뒤 공개되니까 그때 기사 읽어....미안 영알못이라 ㅠㅠ

그래도 요즘 보안이슈등으로 라이브패치에 대한 관심이 많아져서 흥미로운 기사라 오랜만에 포스팅한다

Oracle KSPlice 의 방식도 나중에 포스팅 해보겠다.. 끝

** Notes : 관련해서 이미 공개된 기사들 링크
- http://lwn.net/Articles/634649/
- http://lwn.net/Articles/658333/



posted by mirr

댓글을 달아 주세요

Skills/mY Technutz 2016. 1. 14. 23:08

정말 백만년만의 글인가.... 하고 보니 작년 6월에 글 썼었네... ㅎ


일년에 두개정도면 많은거 같은데..


무튼 어느순간 일이 증가하고, 같이 일하는 사람들이 생겼다 없어졌다 다시 생기는 등


신경써야 할 것들이 많았던 터라 영 공부를 할 수 없었는데,


최근 회사 엔지니어들이 주고받는 메일링 리스트를 보고 다시 이쪽저쪽 들쑤시려고 하는 중...


메일링 리스트에 고객이 많은 메모리를 쓰고 있고, 어떤 이슈가 생겨서, kdump 설정을 통해 덤프를 떠


분석하려고 하는데 이게 자꾸 설정이 안된다는 것이다..


답변으로 오는 것들은 대부분 이것저것 crashkernel 값을 조절해 보라 정도...


그래서 살펴보았다 어떤 공식을 통해 해당 영역이 Allocation 되는지를 말이다.




여기서 내 결론은 일반적으로 crash kernel 은 전체 메모리를 완벽하게 다 뜬다고 볼 수 없으며,


Kernel 에 대한 영역을 위주로 커널이 갖고 있는 PTE 등의 Linked List 정보를 덤프한다고 볼 수 있으므로,.


물리적 메모리 양이 많이 있다고 해서 crashkernel 을 무턱대고 올리는 것이 아니라,


2G - 256M 를 기준으로  64M 씩 올려가면서 테스트 해야 한다는 것이다...


참고로 레드햇 기준으로는 2G-256M, 6G - 512M, 8G - 768M, 그 이상이어도 869M 넘지 않도록


권고하고 있다... ( 난 8G - 768 M 도 too much 하다고 본다.. )


이슈에 대한 추이가 기대되는 부분이다...














posted by mirr

댓글을 달아 주세요

  1.  Addr  Edit/Del  Reply BlogIcon k

    최대...768m...그정도면..1tb 메모리도이상없는듯...
    메모리보다는....장착되어있는..디바이스에 따라 차이를 보이는듯하네요...물론..메모리도 상관 있는듯...

    2016.01.15 18:56
    •  Addr  Edit/Del Favicon of https://seblog.mirr4u.com BlogIcon mirr

      드라이버 등에 영향을 받을 수 는 있죠, 문제는 100테라 넘는 애들에 대한 문제인데, 이부분에선 사실 글에서 언급하지 않은 copy_to_user 의 개선이필요하다고 보는거죠 이부분에서 memcpy 부분의 효율 개선이나 다른 방식의 improve 가 필요하다고 봐요.. OOM 이 발생했다는게 이슈니까요 ㅎㅎ

      2016.01.16 00:14 신고
  2.  Addr  Edit/Del  Reply BlogIcon k

    최대...768m...그정도면..1tb 메모리도이상없는듯...
    메모리보다는....장착되어있는..디바이스에 따라 차이를 보이는듯하네요...물론..메모리도 상관 있는듯...

    2016.01.15 18:56
  3.  Addr  Edit/Del  Reply Favicon of http://seblog.mirr4u.com BlogIcon 미르

    낚임.. 결국 800M 로 덤프 성공.. OOM 부분은 역시 각종 모듈이 영향을 준 것이긴 한데, kdump 에선 이를 위해 blacklist 라는 옵션을 kdump.conf 레벨에서 제공..
    이를 다 블랙리스트로 처리하고 dump 를 뜨면 충분히 떠진다는 점....

    2016.01.18 15:20