요즘 작성하고 있는 커널 모듈 코드에 네트웍 세션 관리를 하는 부분이 있습니다. 오늘 이 코드가 이상하게 동작한다는 것을 우연히 알게되었습니다. 평소처럼 코드를 수정 후 곧바로 모듈을 로딩하여 테스트를 할 때는 별다른 문제가 없었는데 장비에 모듈을 올린후 시스템을 재시작하면 부팅 직후에는 세션 관리 코드가 제대로 동작하지 않다가 얼마 간의 시간이 지난 후부터 정상동작을 하는 현상을 목격하였습니다.몇 번의 리부팅 과정을 거치면서 문제가 무엇인지 찾아보니 시스템 재시작 직후에 만들어진 세션들은 세션 타임아웃 시간이 되지도 않았는데 타임아웃이 된 것처럼 삭제가 된다는 사실을 알게되었죠.
세션 타임아웃을 관리하기 위해서 앞에서 얘기한 jiffies 값을 사용하는데 이 값이 부팅 초기에 4바이트 변수가 가질수 있는 최대값보다 약간 작은 값으로 시작한다는 것을 알게 되었습니다. 세션이 타임아웃될 시간은 현재 클럭 틱을 나타내는 jiffies 에 타임아웃 시간을 더한 값으로 설정이 되는데 이 값이 더해지면서 overflow 가 발생하여 세션의 타임 아웃 값이 굉장히 작은 값으로 초기화되면서 세션이 만들어질 때 이미 타임아웃이 된 것으로 처리되고 있었던 것입니다.
시스템이 리부팅되면 jiffies 의 초기값은 당연히 0일 것으로 생각하고 있었는데 뒤통수를 한 대 맞은 셈입니다. 그래서 커널 코드를 찾아보니 jiffies의 초기값을 정의하는 다음과 같은 매크로를 찾을 수 있었습니다.
/*
* Have the 32 bit jiffies value wrap 5 minutes after boot
* so jiffies wrap bugs show up earlier.
*/
#define INITIAL_JIFFIES ((unsigned long)(unsigned int) (-300*HZ))
매크로를 보면 jiffies 는 커널 재시작 후 5분 후에 overflow 가 발생하도록 되어 있습니다. 재밌는 것은 주석을 보면 알겠지만 jiffies 가 오버플로우가 되면서 생기는 버그들을 빨리 발견할 수 있도록 일부러 jiffies의 초기값을 -5분으로 설정한다는 것을 알 수 있습니다.
만약 jiffies 변수의 초기값이 그냥 단순이 0이었다면 overflow 되면서 생기는 버그를 모른체 제품이 설치가 되었을 지도 모르고 설치 직후에는 잘 동작하는 것처럼 보이다가 언젠가 jiffies 변수가 overflow 될 때 쯤에 는 사용자가 인터넷을 할 수 없는 사태가 발생할 수도 있었을 것입니다. 이런 문제는 제품이 설치 된 이후에는 발견하기도 어려울 뿐더러 문제를 발견하더라도 재현하고 디버깅하는 것이 쉽지 않았을 것입니다.
소프트웨어의 결함은 빨리 발견할수록 결함을 수정하는 비용은 적게 들기 마련입니다. 결함을 빨리 발견하기 위해서 테스트를 빨리, 자주 하는 것 외에도 코드에 결함을 발견할 수 있는 장치를 마련해 두는 것도 필요하다는 것을 알게되었습니다. 코드의 버그를 조기에 발견할 수 있도록 jiffies의 초기값을 조정해 놓은 커널 개발자의 센스 덕분에 귀중한 경험을 하게 되었네요.
