어제의 이야기

어제 공부한 것

어제 퀴즈...
클럭 알고리즘 클럭 포인터 움직이는거 틀렸고
쓰래싱 설명 좀 틀렸고
나머지는 그럭저럭...?

• spt copy에서 type 참조 시 page->operation->type으로 참조. (uninit 안에 있는거 말고.) memcpy도 PGSIZE 로 수정. (페이지 단위로 하니까 그야 그렇겠지만..)

fork read 에서 멈춰 진행이 안되는 상황 발생.

• kill 방식을 도는게 아니라 hash_clear함수를 사용하여 거기에 쓸 부가 함수를 만들어 주어 돌림. 해결되지 않고 양상 동일.

• fork중 wait 부분이 안되길래(정확히는 sema down이) 그 부분이 문제인가? 했는데 spt find만 주석 처리한 경우, memcpy를 주석처리 각각 한 경우는 여전히 멈추는데, 그거 둘다 주석처리하면 멈추는 현상이 사라짐. 하지만 거기에 들어가는 인자는 포인터가 멀쩡히 찍힘.

• 다른 코드를 참고했더니 uninitq 케이스의 경우 memcpy를 진행하지않음.(당연함! uninit 상태에서는 데이터도 없을테니. 그래서 null 에러가 나는 것.) 그래서 if문으로 해당 타입을 따로 빼줬더니 fork 성공했으나...

read 케이스에서 parent process 가 exit(-1)로 종료되는 상황 발생.

• read에서 쭉 추적했더니 check address에서 pml4 get page가 안 되는 케이스에서 죽음. 여기선 죽는게 당연한게, uninit된건 pml4에 아직 set 되지 않았을테니 자료가 없겠지. vm일떄는 체크하지않도록 따로 뺐더니 fork close pass. 단, bad-ptr 케이스가 실패하고 있음.(제대로 따로 안 뺐나본데 어렵네.)

Stack growth.

• pt growth stack 케이스에서 처음 출력되는, 접근하는 주소가 4747fe90. 이걸 페이지 정렬하면 4747e00이 뜨는데. 이건 현재 stack bottom, 즉 스택의 최고치에서 4096, 16진수의 3승, PGSIZE 만큼 차이나는 지점에 접근함.

• 그래서 최대 stack 지점보단 작고, 현재 증가한 스택 포인터보단(이전에 증가한게 있었을테니, rsp 지점이겠지.) 커야한다고 생각했는데...

• rsp가 어떨땐 보존이 되고, 어떨땐 보존이 안 되고에 대한 문장의 파악이 어려웠음. 이제보니 시스템 콜로 넘어올때는 rsp를 따로 저장해야하고, 그 외에는 유저 접근이라 그냥 page fault로 넘어온 intr_frame을 쓰면 됨. 애초에 그 둘의 접근을 구별하는걸 vm try handle fault에서 user라는 변수를 쓰면됨.......

• 그리고 stack growth 처리를, 그냥 page만 일단 initial 해주면 not present 케이스 안에서 알아서 다해줌.........

• stack growth 인 경우의 조건을, rsp는 이미 그 초과하게 넘어온 시점부터 증가하여 이동했기때문에 addr은 rsp와 user stack 사이라면 growth..... (근데 이게 정확히 뭔지 납득이 안되네 좀 찾아봐야겠다)

명령이 호출되면 rsp는 필요한 메모리만큼 이미 이동해있는 상태이다.

명령어 호출시 어셈블리수준에서 rsp가 쌓이기때문인듯...

• rsp-8같은 위치에서 날수도 있으니 따로 뺴주고......

• 나는 막 엄청 큰 사이즈 요구시 여러번 반복해야한다고 생각했는데, 사실 그러면 그떄마다 페이지 폴트나니까 그냥 페이지 사이즈 만큼 한번만 하면 되더라...

stack에서 bad 케이스 말고 통과.

소감

진도를 나가긴하지만..
나가는건?가?

물론 치열하게 유추했지만..
열받아죽을뻔했지만...
디버깅도 열심히했지만...

오늘의 계획

변경 사항 및 일정

랜덤런치.

오전

munmap, mmap 어떻게 하는지 플로우 정리하기.

낮

munmap, mmap 슈도 써보기.

저녁

힘내서 ...힘내기

오늘의 다짐

요즘 왜 이리 잠을 잘 자지
일이 잘 풀리는건지 피곤한건지