Dcache scalability and security modules

LWN 4월 말 기사인것같은데 이제서야 분석한다. (이제 무료전환 풀렸을듯)
( 원문 : https://lwn.net/Articles/440347/ )

간략하게 요약하자면 Dcache 확장성과 보안모듈에 대한 충돌과정과,

패치전에 제대로 만드는것에 대한 중요성(?) 인데,

Dcache ( Dentry Cache ) 에 대한 확장성 패치는 커널버젼 2.6.38 에 Merge 되었고,

이것은 모든 locking 없이 지연되는 Disk 탐색 (경로명 탐색등) 을 수행할때 작동된며,

RCU 메커니즘은 실재로 오랜기간의 Lookup 수행으로 인해 아직 남아있는 

dentry structure 를 보장하기 위해 사용되는데, 

 본문에 링크돼어있는 패치셋으로 인해 커널로부터 주요한

확장성 문제를 제거했고, Looking 타임에서 많은 향상점을 가져다 주었다고 한다.

그런데 그 작업들이 항상 동일하게 작동하지 않는다는 문제점들이 지목됐고, 

오히려 늦게 나오게 된 2.6.39 에서 실질적 문제해결에 도움이 되었다는것..

사실상, RCU 아래에서 빠른 경로명 탐색을 수행한다는 의미는

특별한 Block 작업이 필요 없다는 것이기도 한데, Directory Entry 같은 것들의 경우

Blocking 되지 않고서는 Lookup 작업이 이루어 질 수 없어, fast path 작업이 취소되고,

전체 프로세스는 슬로우 모드로 다시 시작하게 되게 만든다는 얘기..
(상세한건 직접 문서보면 알 수 있다. 특히 본문내에 링크된 문서들)

2.6.38 커널의 Dcache Code 에서는 보안모듈 즉 SELinux 로 인해,

실제 보안모듈이 활성화 되어있지 않더라도 프로세스들의 '슬로우모드' 전환이 

강제적으로 이루어 질 수 있다는 이슈였다....

이것은 보안모듈중 'inode_permission()' 가 RCU 에 대해서 안전성 유무를 

확인하기위한 충분한 시간을 확보하려는 것 때문인데,

그래서 특히 만약 보안모듈이 활성화 되어 있다면, 이것에 대한 결과는

단순히 2.6.37 이상의 커널이 제공하는 확장성이라는 잇점을 사용할 수 없게 된다는 것 뿐 아니라, 

실질적으로 2.6.37 이하의 커널에서 돌아가는 코드들보다 성능에 있어

악영향을 미칠 수 있다는 얘기.....

엔터프라이즈 배포본들 ( RHEL, Debian 등등 ) 에서는 보안모듈을 활성화시키는게

일반적인 경향이므로 이 성능적 문제에대해 정말 관심을 두고 있다고 한다.

이에 대해서, Andi Kleen 이란 사람이 코드를 쭉 몇번 훑어 보더니만,
( 이사람 수세에있다가 지금 Intel Open Source Technology Center 에서 근무)

순식간에 (는 오바인데) 개선방법을 찾아 패치하여 커널 2.6.39-rc5 에 머지된다.

Andi 는 Slow mode 로 전환시킬때 기본적으로, RCU 모드에서 안전하게 inode 권한에 대한

확인 가능 여부를 각각의 보안 모듈별로 허용하도록 분리시키는 방법부터

접근하기 시작했고, 기존의 inode_permisstion() 모듈이 아무것도 체크를 안하게 된 이후로는, 

RCU-safe 상태의 구현이 매우 쉬워졌다고 한다.

이런저련 변화로 인해, 보안모듈이 활성화되고 포함된 시스템이라도

Fast Path Lookup 이 가능하게 만들었다는....(천재다 진짜...천재 너무많다..)

웃기는건 이사람이 코드를 수정하는 과정에서 이미 SELinux 와 SMACK 등의 

보안모듈에 permission check 시 RCU 를 사용하고 있음을 알게 되었고,

그 코드가 이미 그렇게 RCU-safe 상태였다는걸 감안해 보면,

RCU-safe 한 permission  check 를 비교적 수월하게 할 수 있게

가이드해주고 있었다고 봐도 됐다는거지....

물론 보안감사 ( Auditing ) 에 대한 RCU 부분이 처리되지 않았던 상태고,

그부분에 의해 시스템을 느리게 만들어버리는 결과가 생기긴 했지만...

이 기사를 쓰는 Jonathan 은 아무리 그랬다고 해도, Dcache Scalability 패치를 할때부터

보안모듈이 적용된 시스템들까지도 고려하며 작업을 했어야 했다고 까는것....같은데... ㅋㅋ

마지막 문구에선, 이렇게 Late-Cycle 즉 마지막주기에 패치를 해대는것보다

오히려 초기부터 안전하고 여러가질 고려한 프로그래밍을 했어야 한다는

말로 난 이해했는데....뭐 대강 이런 내용이고,

오역도 있을 수 있어서 본문을 직접 보는게 좋을듯....

dcache 에 대한 내용을 살펴보는것도 좋고, IBM Development Libraries 에도

RCU 등에 대한 좋은 문서들 많이 있으니 참조하시면 좋을듯함...
(아직 기사 세개 더 정리해서 써야.......쿨럭)