안녕하세요.

Userspace에서 커널 모듈을 이용할때, open 하고 ioctl을 쓰잖아요?

혹시 Userspace의 ioctl에서 부터 커널모듈의 ioctl 에 도달하기까지 과정을 디버깅을 하고 싶을때는 어떻게 해야 하나요?

gdb나 그런것은 쓸 수 있는 환경이 아니구요, 그저 프린트문에만 의존해서 디버깅을 해야 하는데, 그 중간과정에 glibc 라이브러리가 중개하는 건가요? 아니면, 커널소스 자체만으로도 충분히 디버깅을 할 수 있는것인가요.

아시는분 알려주시면 감사하겠습니다.

ioctl 그 자체로 system call입니다. 아래 링크를 참조하세요.
h t t p://kldp.org/KoreanDoc/html/EmbeddedKernel-KLDP/device-understanding.html

답변 감사합니다. 어제는 다른 급한 일이 있어서 다른 일 처리했는데, 오늘 ioctl 문제를 다시 보려고 오니, 여기에 몇몇분들이 답변을 해주셨네요.

제가 분석한 결과는,

User Space ioctl -> GLIBC Processing -> Kernel Space ioctl

로 들어가는 것 같습니다.

제가 발견한 문제는 User Space ioctl의 파라미터가 아주 rarely Kernel Space ioctl로 전달이 되는 과정에서 corrupt 되는 경우가 있더라구요. CPU는 MIPS IV 입니다. 아무튼, 그래서 GLIBC를 뜯어보기로 했습니다. (제가 기억하기로는 system call은 glibc로 들어가는 것 같거든요. 그리고 파일시스템을 거쳐서 비로소 커널의 ioctl로 inode와 함께 전달해 주는게 아닌가 합니다.) 아니면, User Space의 TaskID와 Kernel Space TaskID를 비교해 보는 것도 도움이 될 듯 싶구요.

copy_from_user도 뜯어보았는데, 거기서는 문제를 발견하지 못했습니다.

아무튼 답변들 감사합니다. workingus에 질문하기를 잘했다는 생각이 드네요.

kldp에도 같은 질문을 올렸는데, kldp에서 확인을 안하고, 여기를 먼저 확인했다가, 혹시나 해서 kldp에 갔더니, 다른 분들이 또 답변을 해주셨네요.

다행스럽게도 glibc를 뜯지 않아도 될 듯 싶습니다. glibc에서 바로 fs/ioctl.c의 sys_ioctl로 들어가는 것 같으니, fs/ioctl.c 부터 추적하면 될 것 같습니다.

감사합니다.

그거시님 답변 감사합니다.

우선 문제가 쉬운 reproducible 한 것이 아니긴 합니다. 대략 20분에 한번정도 나올까 말까 하는데, timing issue 가 있는 것 같습니다.

strace를 쓸 수 있는지는 한번 확인 해 봐야겠습니다. strace를 몰랐는데, 매우 유용한 툴이네요. 한번 확인해봐야겠습니다. 문제는 strace 소스를 받아서 mips용으로 컴파일해야 한다는 것과…application이 read-only filesystem에서 돌아간다는 것..(이건 usb mounting으로 redirect 해서 결과를 뽑으면 될듯 싶네요.) 그리고 application이 커널 부팅이 끝나면서 바로 실행되는 것이라, 그 사이에 usb mount 하고, strace로 redirect 해서 usb device로 결과가 나오게 하면 될 듯 싶지만…application이 돌아가는 것이 상당히 무겁게 많은 일을 처리하고 있는 것이라, 딱 내가 원하는 부분만 strace로 할 수 있는지 모르겠습니다. 그러나 확인해 볼만한 가치가 충분히 있네요.

감사합니다.

Debugging output을 말씀하시는 것이라면, serial port를 씁니다.

다행스럽게도 프린트를 수정해서 queue에 집어넣고, 적당하게 낮은 priority thread로 돌다가 간섭해도 되겠다 싶으면, 그때 나와서 프린트 뿌려주고 사라지고…하다가…max queue에 도달하면, 그냥 프린트 안하는 그런식이라, kernel을 블락하는 것을 우선 최소화는 해 두었습니다.

dietlibc repository는 처음 들었는데, 가보니 재미있네요. Delicious Bookmark 해 두었습니다.

우선 확인한 것이 kernel module ioctl에 들어서면서 망가진 것이 확인 되었고, user space의 ioctl은 정상인것이 확인이 되었으므로 그 중간에 뭔가가 문제가 있거나, 아니면 잘못된 pid가 intercept했거나 하는 speculation을 하고 있습니다. 만일 fs/ioctl.c 에서부터 잘못이라면, glibc가 문제인 듯 하니, glibc를 뜯어야겠지만…아니기를 바래야지요.

late 80s에 MIPS를 쓰셨다니!!!!! 그 당시 저는 Z-80 ( 으로 최근 코나미사에서 히데오 코지마 프로덕션의 (올해 4월1일부로) 메니징 디렉터로 성공가두를 달리고 있는 히데오 코지마의 메탈기어하느냐고 밥먹는거 스킵할때였는데…..쩝…