(2022.03.08) Stack Growth 가이드라인

현타 오는게 지금까지 뭔가 많이 한 거 같은데 결과는 프로젝트 2의 복원에 불과하다. ㅋㅋㅋㅋ.... 이제 좀 본격적으로 프로젝트 3의 내용을 좀 짜보자.

 

이전 포스팅에서 조금씩 언급해온 stack growth를 구현하는 것이 해당 소주제에서 이뤄야 할 과제이다. pintos는 여지껏 stack은 단 한 개의 페이지로만 운영되어 왔다. 프로세스를 로딩할 때 argument가 들어갈 페이지를 제외하고는 할당해주지 않았었다. 그러나 이제부터는 stack의 공간을 추가적으로 할당할 필요가 있으면, 해당 페이지를 할당해주어야 한다. 

 

stack 공간을 할당할 때, 일반적인 실행 파일이 로딩되는 것과 다른 점은, stack 주소는 spt에 struct page로서 매핑이 되어 있음이 보장되어 있지 않다는 것이다. 때문에 지금의 루틴대로라면 vm_try_handle_fault에서 대응이 되지 않은 채로 강제종료될 것이다. 따라서, vm_try_handle_fault를 수정해서 stack growth인 경우를 잡아내도록 해야 한다. 만약 해당 경우라면, 다음의 함수를 호출해서 대응하도록 해야 하는데, 이 또한 이번에 구현할 함수이다.

void vm_stack_growth (void *addr);

해당 함수들을 정정하면 테스트 케이스 중 pt-grow가 붙은 케이스를 모두 통과할 수 있을 것이다.

 

그외 매뉴얼에서 구현에 참고할 사항은 다음과 같다. 많은 OS에서 스택이 가질 수 있는 절대적인 크기를 지정한다고 한다. pintos에서도 1MB로 스택이 자랄 수 있는 한계를 지정해놓으라고 한다.

 

또 유의할 사항이 있다고 한다. system call이나 유저 프로그램에 의해 발생한 page fault의 경우에는 현재 rsp가 struct intr_frame에 제대로 들어있기 때문에 stack growth의 참조용으로 쓰는데 문제가 없다. 그러나, 만약 커널에서 이러한 page fault가 발생한다면, page_fault로 넘겨진 intr_frame 내의 rsp가 유저 스택 포인터가 아닌 쓰레기 값을 들고 있다고 한다. 따라서, 커널에서 page fault가 발생할 경우를 대비해 유저 스택 포인터를 thread 구조체에 저장할 필요가 있다고 한다. 이를 염두해서 코딩하도록 한다.

 

이번 가이드는 짧다. 바로 코딩하자.