PANIC
Posts
11 posts[Linux][Kernel] Kernel Panic @__stack_chk_fail - 스택 카나리 (Stack canary Feature)
최근 흥미로운 커널 패닉이 나왔는데요. 디버깅 과정을 공유 좀 하고자 해요. 일단 콜스택부터 볼께요. sock_has_perm() 함수가 돌다가 갑자기 __stack_chk_fail() 함수 호출로 panic()이 일어났거든요. 왜 이런 현상이 발생했을까요?crash> bt e5752c00PID: 1787 TASK: e5752c00 CPU: 4 COMMAND: "net_socket"bt: WARNING: stack address:0xe853fa38, program counter:0xc0ee5b60 #0 [ ] (panic) from [ ] #1 [ ] (__stack_chk_fail) from [
[Linux][Kernel] panic@___might_sleep
리눅스 커널 synchronization의 꽃 중의 하나인 Mutex Lock에 대해서 조금 짚어 볼께요. Mutex Lock은 보통 스핀락(Spinlock)과 많이 비교하죠. 사실 소스 코드를 보면 Mutex Lock이 스핀락보다 훨씬 소프트웨어적으로 복잡해요. 그 이유는?1> Mutex Lock을 잠근 프로세스만 해제할 수 있어요2> 이미 다른 프로세스가 Mutex Lock을 획득한 상태면 struct mutex.wait_list에 대기하고 Wait Queue에 넣고 잠들어야 해요.음, 이 소리는. Mutex Lock을 잡고 있는 프로세스가 Mutex Lock을 해제하면 누군가가 다시 대기 중이던 프로세스를 WaitQueue에서 끄집어 내서 런큐에 큐잉을 해줘야겠죠. 마지막으로 Mutex
[Kernel][Debug] "cat /d/shrinker" kernel panic
100% 커널 패닉으로 타겟이 죽어버리는 이슈를 발견했어요.자자, 일단 커널 로그부터 좀 볼까요? 뭐, PID가 6978이 sh 프로세스에서 do_raw_spin_lock() 함수에서 데이터 어보트를 유발시켰네요.[ 761.636711] Unable to handle kernel paging request at virtual address f38a9a84[ 761.645048] pgd = e8074000[ 761.649800] [f38a9a84] *pgd=a0721811, *pte=00000000, *ppte=00000000[ 761.658106] Internal error: Oops: 7 [#1] PREEMPT SMP ARM[ 761.665481] Modules linked in:[ 761.6
