LINUX
Posts
477 posts[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
[Linux][Kernel][Stability] Kernel panic @0x0 from xfrm_local_error+0x4c
커널 패닉이 났어요.네트워크 드라이버 리눅스 커널 코드에서 발생한 것 같은데요. 음.일단 당황하지 마시구요. 차근 차근 커널 로그와 코어 덤프를 살펴보면, 정답이 나와요. 일단 커널 로그를 보면, 프로그램 카운터가 0x0을 가르키고 있네요.음... 그리고링크 레지스터(R14)가 0xc0adc274(LR is at xfrm_local_error+0x4c/0x58) 을 가르키고 있습니다.[ 262.401303] Unable to handle kernel NULL pointer dereference at virtual address 00000000[ 262.401365] pgd = dbdc4000[ 262.401389] [00000000] *pgd=00000000[ 262.401433] Internal
tombstone 시(시스템 크래시) - 커널 패닉 유발
userspace에서 tombstone(무덤)이 떨어지면서 크래시가 종종 발생합니다.에러 시그니처는 아래와 같아요. 흠...Revision: '0'ABI: 'arm'pid: 1558, tid: 1891, name: RenderThread >>> com.google.launcher2
Spinlock(스핀락) - Deadlock 시나리오
자자, 이제 A, B, C 모듈에서 spinlock을 순서대로 잡는 시나리오를 만들어 볼께요.spinlock value는 특정 메모리 공간에 있는 전역 변수와 같다고 보면 되요. 1. A 모듈이 스핀락을 겁니다.spinlock valuenext | owner0001 0000 2. B 모듈이 스핀락을 겁니다. 자 이때 A모듈이 스핀락을 잡고 있어요. spinlock value next | owner 0001 0000 //<<-- arch_spin_lock() 진입 전 next값을 로컬 변수에 저장, 자 그럼 로컬 변수 lockval.tickets.next=1, lockval.tickets.owner=0 이겠죠 0002 0000 // spinlock value next를
![[웹툰단행본] 『통제구역관리부』 1권 후기 : 이상한 변칙과 기이한 일들이 일어나는 공간에 대하여](https://img.zoomtrend.com/2026/06/09/1780996474-SE-5eda86fa-0d63-4afd-b8dd-b801879fed52.jpg)
