운영체제

x86 syscall 테이블의 두 번째 컬럼은 common, 64, x32 중 하나여야 한다. comoon은 그 어느 것도 아니다. arch/x86/syscalls/syscalltbl.sh는 이 컬럼을 대문자로 바꿔 __SYSCALL_<ABI>(...) 매크로 이름을 그대로 조립하므로, 생성되는 syscalls_64.h에는 정의된 적 없는 __SYSCALL_COMOON(323, sys_get_task_info, sys_get_task_info)이 들어간다. 즉 64비트 시스템 콜은 등록되지 않는다.

바로 윗줄 322 64 execveat과 비교하면 오타가 눈에 보인다. 32비트 테이블(syscall_32.tbl:368)의 i386은 정확히 적혀 있으므로, 이 과제는 32비트에서만 동작하고 64비트에서는 동작하지 않는 상태로 제출됐다. 참고로 두 줄 모두 번호 뒤가 탭이 아니라 공백인데, 이쪽은 스크립트가 공백 구분으로 읽으므로 무해하다.

미검증: 4.1 커널을 이 환경에서 빌드할 수 없어, 실패 형태가 컴파일 에러인지 조용한 누락인지는 확인하지 못했다. 어느 쪽이든 64비트 등록이 안 되는 결론은 같다.

sys_get_task_info는 asmlinkage long인데 함수 본문에 return이 없다. 시스템 콜의 반환값은 유저 공간이 성공/실패를 판정하는 유일한 채널이고, 여기서는 레지스터에 남아 있던 쓰레기값이 그대로 errno 해석 대상이 된다. 함수 전체가 9줄이고 그중 빠진 것이 return 0; 한 줄이다.

덤으로 task->state는 4.1에서 volatile long인데 %x로 출력한다 — 상위 32비트가 잘린다. task->flags(unsigned int)와 nr_dirtied(int)는 맞다.

linux/kernel/get_task_info.c를 새로 만들었지만, 이 파일을 빌드에 넣어 주는 kernel/Makefile의 obj-y 추가가 저장소에 없다. 저장소에 있는 Makefile은 driver/Makefile 하나뿐이다. README가 선언한 "Week(n) done: 과제로 변경한 파일을 커밋한다"는 규칙이 이 커밋에서 이미 지켜지지 않았다는 뜻이고, 선택지는 둘뿐이다 — 로컬에서 고쳤지만 커밋을 빠뜨렸거나(규칙 위반), 애초에 안 고쳐서 get_task_info.o가 링크되지 않았거나(빌드 실패). 어느 쪽이든 이 커밋만으로는 과제가 재현되지 않는다.

README.md:6은 "directory linux: linux-4.1.38 kernel"이라고 적었지만 linux/에 있는 것은 수정한 파일 4개뿐이다. 변경분만 커밋한 판단은 옳다 — 잘못된 것은 README의 문장이다.

세 프로그램 전부 msgget((key_t)1234, IPC_CREAT | 0666)으로 큐를 생성하는데, 저장소 전체에 IPC_RMID가 한 번도 등장하지 않는다. msgctl 호출은 receiver.cpp:36의 IPC_STAT 하나뿐이다. SysV 메시지 큐는 프로세스가 아니라 커널에 매달린 자원이므로, 프로그램이 끝나도 키 1234의 큐는 남는다. 실습을 반복 실행하면 이전 회차의 잔여 메시지가 다음 회차 receiver로 들어간다 — 종료 조건이 seq == 1000 센티넬 2개를 세는 방식(receiver.cpp:55–60)이라, 잔여 센티넬 하나만 남아 있어도 결과가 뒤틀린다.

생성/삭제 짝을 맞추는 것이 이 실습의 절반이다. 0666 권한까지 붙여 아무나 읽고 쓸 수 있는 큐를 남기는 것은 덤이다.

msgrcv의 msgsz는 mtype(long) 뒤의 수신 가능 바이트 수다. 송신 측은 sizeof(struct msg_buf) - sizeof(long) = 264를 정확히 쓰는데(sender.cpp:42, psender.cpp:51), 수신 측만 sizeof(struct msg_buf) = 272를 넘긴다. 이 프로그램의 송신자들이 264바이트만 보내므로 지금 당장 터지지는 않지만, 264바이트를 넘는 메시지가 큐에 하나라도 있으면 커널이 mybuf 끝을 8바이트 넘겨 쓴다. 그리고 위 항목대로 이 큐는 지워지지 않고 권한이 0666이라, 다른 프로그램이 큐에 넣은 메시지가 들어올 수 있다.

receiver.cpp:48–65는 모든 메시지를 vector에 모아 두었다가 끝에서 prio 필드로 sort한다. SysV 메시지 큐가 우선순위를 표현하는 수단은 mtype과 msgrcv의 음수 msgtyp 인자인데, 여기서는 mtype이 모든 메시지에서 4로 고정이고 우선순위는 페이로드 안의 그냥 정수다. 큐가 우선순위를 다루는 것을 보이는 실습에서, 큐는 우선순위와 아무 관련이 없고 std::sort가 전부를 한다.

같은 맥락에서 psender.cpp:31의 setpriority(PRIO_PROCESS, pid, 0)은 nice 값을 0으로 두는 것이라 아무 효과가 없고, 반환값 ret은 어디에서도 읽히지 않는다.

Tanenbaum 해법에서 test()가 하는 일은 상태를 EATING으로 바꾸고 세마포어를 post하는 것뿐이다. 실제 식사는 락을 놓은 뒤 각자의 스레드에서 일어난다. 이 구현의 test()는 eat(i)를 직접 호출하고, eat()은 usleep(EAT_TIME * 10000)으로 30ms를 잔다 — 그것도 lock을 쥔 채로. get_chop은 sem_wait(&lock)과 sem_post(&lock) 사이에서 test(i)를 부르므로, 한 철학자가 먹는 30ms 동안 나머지 넷은 전역 락에서 대기한다.

이 과제가 존재하는 이유는 "이웃하지 않은 철학자 둘이 동시에 먹을 수 있는가"이고, 이 구현에서 그 답은 아니오다. 데드락이 없는 것은 맞지만, 그것은 회피 전략이 작동해서가 아니라 동시성이 하나도 없기 때문이다. 전역 락 하나로 모든 것을 감싸면 식사하는 철학자 문제는 성립하지 않는다.

부작용도 있다. put_chop에서 test(LEFT(i))가 조건을 만족하면, 이웃의 식사가 이웃 스레드가 아니라 자기 스레드에서 실행된다(dining.cpp:94–95). 깨어난 이웃은 이미 밥을 다 먹은 상태로 sem_wait(&chopstick[i])를 통과해 곧바로 put_chop으로 간다. num_eat 집계는 맞지만 스레드와 행동의 대응이 깨져 있다.

for (i = 0; i < 10; i++) 안에서 i == 10을 검사한다. 루프 조건상 i는 10이 될 수 없으므로 이 분기는 영원히 죽은 코드다. 문제는 만약 조건이 성립하도록 고쳤을 때 — break가 pthread_mutex_unlock 앞에 있어서, 스레드는 뮤텍스를 쥔 채로 루프를 나가고 종료한다. 상대 스레드는 do_ops2의 pthread_mutex_lock에서 영구 대기하고, main의 pthread_join도 돌아오지 않는다. 대칭 함수인 do_ops2에는 이 분기가 아예 없어, 실수로 남은 코드임이 더 분명해진다.

-Wall -Wextra가 dining.cpp에서 미사용 변수를 다섯 개 잡아낸다: t(:116), args(:117), minCount·maxCount(:118), left·right(:101). minCount/maxCount는 USHRT_MAX로 초기화까지 해 놓고 쓰지 않는데, 철학자별 식사 횟수의 최소/최대를 비교해 기아를 판정하라는 스켈레톤의 의도가 그대로 드러난다 — 그 판정은 구현되지 않았다. :126의 /* TODO: Thread create & destroy */ 주석도 남아 있다. sem_destroy는 어디에도 없다.

또 dining·do_ops1·do_ops2·thread_func 네 스레드 함수가 전부 void*를 선언하고 return하지 않는다(-Wreturn-type).

tick()은 밀리초를 돌려주는데, t -= tick()/1000 - start_time/1000;은 두 값을 각각 초 단위로 내림한 뒤 뺀다. 한 번의 get_chop+put_chop은 50ms 남짓이므로 대부분의 반복에서 이 차이는 0이고, t는 벽시계의 초 경계를 넘을 때만 줄어든다. 결과적으로 3초 근처에서 끝나기는 하지만 그것은 경과 시간을 잰 결과가 아니라 초 경계를 세 번 넘은 결과다. start_time을 루프 밖으로 빼고 밀리초로 비교했으면 될 일이다.

출력 쪽에도 같은 종류의 부주의가 있다. :142의 printf("%lld.%lld sec", (end-start)/1000, (end-start)%1000)은 하위 자리를 0으로 채우지 않아 1005ms를 1.5 sec로 찍는다.

여섯 줄 모두 포인터를 %08x로 넘긴다. x86-64에서 %x는 unsigned int 변환이므로 상위 32비트가 사라진다. 커밋된 바이너리 memory/manage는 ELF 64-bit x86-64이니, 이 프로그램은 자기가 실행되는 바로 그 아키텍처에서 주소를 잘못 찍는다. 컴파일러가 여섯 줄 전부를 -Wformat으로 지적한다.

같은 코드를 macOS에서 빌드해 실행한 결과가 그 효과를 그대로 보여 준다. 실제 스택 주소가 0x16f651d7c일 때 %08x는 0x6f651d7c를 찍는다 — 최상위 니블이 통째로 사라져, 스택이 힙보다 낮은 주소에 있는 것처럼 보인다. 메모리 레이아웃을 관찰하는 것이 목적인 과제에서 레이아웃을 잘못 보여 주는 출력이다. %p 한 글자면 해결된다.

handle = dlopen("/lib/libc.so.6", RTLD_LAZY)의 반환값을 검사하지 않고 곧바로 dlsym(handle, "printf")를 부른다. 경로가 하드코딩이라 멀티아치 배포판(/lib/x86_64-linux-gnu/libc.so.6)에서는 handle이 NULL이 된다. glibc에서 NULL 핸들은 RTLD_DEFAULT와 같은 값이라 우연히 동작할 수도 있는데, 그 "우연히 동작함"이야말로 검사를 넣어야 하는 이유다.

실제로 같은 코드를 macOS에서 실행하면 dlopen이 실패해 library: 0x00000000이 출력된다. 프로그램은 오류 없이 0을 정답인 양 찍고 종료 코드 0으로 끝난다. dlerror() 호출은 파일 어디에도 없다.

class_create가 실패하면 IS_ERR(myclass)가 참이 되어 두 가지 일이 연달아 일어난다. 첫째, class_destroy(myclass)가 에러 포인터를 실제 포인터처럼 역참조한다 — 실패한 객체를 해제하려는 시도이고, 커널 oops로 이어진다. 둘째, 반환값이 PTR_ERR(myclass)가 아니라 PTR_ERR(mydevice)다. mydevice는 :15에 선언만 되고 이 파일 어디에서도 대입되지 않는 전역이므로 값은 NULL이고, PTR_ERR(NULL)은 0이다.

즉 insmod는 성공을 보고한다. 모듈은 클래스가 없고 cdev도 등록되지 않고 mydrv_data도 할당되지 않은 상태로 커널에 적재되며, 이후 rmmod가 mydrv_cleanup을 불러 NULL mycdev에 cdev_del을 시도한다. 실패를 성공으로 보고하는 것은 어떤 초기화 함수에서도 최악의 실패 모드이고, 여기서는 변수 이름 하나를 잘못 적어서 발생했다.

벌크 전송에서는 copy_to_user/copy_from_user를 정확히 쓴다. 그런데 두 함수 모두 맨 첫 줄에서 유저 공간 포인터 buf를 printk의 %s에 그대로 넘긴다. 커널 문맥에서 유저 메모리를 직접 읽는 것이고, SMAP이 켜진 x86에서는 그 자리에서 폴트가 난다. SMAP이 없어도 문제다 — %s는 count를 모르므로 NUL을 만날 때까지 읽고, 유저가 보낸 데이터에 NUL이 없으면 매핑 경계를 넘어 커널 로그로 흘러 나간다.

mydrv_read의 경우는 한 겹 더 나쁘다. :32의 printk가 :33의 buf == NULL 검사보다 앞에 있어서, NULL을 걸러내려고 넣은 검사가 이미 NULL 역참조가 일어난 뒤에 실행된다. 게다가 read의 buf는 아직 채워지지 않은 출력 버퍼라, 찍히는 내용은 의미 없는 쓰레기다.

덧붙여 count < 0 검사는 count가 size_t(부호 없음)이므로 항상 거짓인 죽은 코드다.

grep device_create의 결과가 비어 있다. 클래스는 만들지만 디바이스 노드는 만들지 않으므로 /dev에 아무것도 생기지 않고, 사용자는 mknod로 직접 만들어야 한다. 그런데 정리 코드는 만든 적 없는 디바이스를 두 번 파괴하려 한다 — :84(cdev_add 실패 경로)와 :97(mydrv_cleanup). 인자로 넘기는 myclass는 유효하므로 device_destroy는 해당 devt를 찾지 못하고 조용히 돌아가지만, 자원 획득/해제 짝이 애초에 맞지 않는다는 신호다.

동봉된 유저 테스트는 이 불일치를 그대로 드러낸다. usertest.c:10은 /dev/device_driver_test를 여는데, 드라이버가 등록한 이름은 DEVICE_NAME "mydrv"(:9)다. 두 이름 중 어느 것도 자동으로 생성되지 않으므로, 이 테스트는 손으로 만든 노드 이름이 우연히 맞아떨어질 때만 동작한다.

:89의 kmalloc(4096, GFP_KERNEL)은 검사 없이 mydrv_data에 대입된다. NULL이면 이후 첫 write의 copy_from_user(mydrv_data + offset, ...)가 NULL 근처에 쓴다. cdev_alloc()(:80)의 반환값도 검사 없이 mycdev->ops로 역참조한다.

mydrv_cleanup은 순서가 거꾸로다. kfree(mydrv_data)가 cdev_del(mycdev)보다 먼저 실행되므로, 그 사이에 진행 중이던 read/write는 해제된 버퍼를 만진다. cdev_del을 먼저 불러 새 open을 차단한 뒤 버퍼를 놓아야 한다.

grep으로 mutex·spin_lock·atomic·down( 어느 것도 발견되지 않는다. mydrv_read_offset과 mydrv_write_offset은 모듈 전역이고 두 핸들러가 잠금 없이 읽고 쓴다. 두 프로세스가 동시에 write하면 mydrv_write_offset += count가 서로를 덮어쓰고, 버퍼는 겹쳐 쓰이며, :52의 경계 검사도 무의미해진다.

구조적으로도 ppos 인자를 두 핸들러 모두 무시한다. 파일 오프셋이 struct file이 아니라 모듈에 달려 있으므로, 두 프로세스가 각자 open해도 커서를 공유한다 — 먼저 읽은 쪽이 전부 가져가고 두 번째는 0바이트를 받는다. 마지막으로 :53은 버퍼가 가득 찼을 때 0을 반환하는데, write()의 0 반환은 "진전 없음"이라 이를 재시도 루프로 처리하는 호출자를 무한 루프에 빠뜨린다. -ENOSPC여야 한다.

buf_out은 char[26]인데 인덱스 27에 대입한다 — 유효 범위는 0..25이므로 두 칸 밖이다. 전역 배열이라 실제로는 인접한 buf_in의 어딘가를 건드릴 뿐 눈에 띄지 않지만, 컴파일러가 경고 한 줄로 잡아 준다. 같은 파일은 <unistd.h>를 include하지 않아 read/write/close가 선언 없이 쓰인다.

file로 확인하면 mutex/mutex.o, message_queue/receiver.o 등이 ELF 64-bit LSB executable, dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2다. 재배치 가능한 오브젝트가 아니다. gcc -c foo.cpp 대신 gcc -o foo.o foo.cpp로 빌드해 실행 파일에 .o 확장자를 붙인 것이고, 여섯 개가 전부 그렇다. 빌드 산출물을 커밋한 것보다, 자기 툴체인이 무엇을 만들었는지 확인하지 않은 쪽이 문제다.

.o 6개, .ko 1개, .mod.o, .cmd 3개, Module.symvers(0바이트), .tmp_versions/, modules.order, 그리고 링크된 실행 파일 memory/manage·driver/usertest — 합쳐서 534KB, 소스 전체보다 훨씬 크다. .gitignore는 없다. 커널 빌드가 생성한 .cmd와 modules.order에는 빌드 머신의 절대 경로 /home/practice/Workspace/ele3021이 그대로 남아 있다. 시크릿은 아니지만, 아무도 열어 보지 않고 커밋했다는 증거다.

origin/2018은 2017년 커밋 11개 위에 Rebase(d9cc95e, 2018-03-20) 하나를 얹은 브랜치다. 그 커밋이 하는 일은 2017년의 모든 소스 35개를 삭제하고 project1/simple unix shell.pdf 하나를 추가하는 것이다(3,596줄 삭제, 3줄 추가). README도 - [ ] Simple User-level Unix Shell 한 줄의 미체크 체크박스로 교체된다. 2018년에 같은 과목을 다시 들으면서 저장소를 비우고 시작했으나, 그 이후 커밋은 없다 — 체크박스는 8년째 비어 있다.

기본 브랜치가 아닌 곳에 더 완성된 구현이 있는지 확인했고, 없다. master가 이 저장소의 전부다.