Ost 커널 크래시 (ctl_enqueuedata 내부)

내 코드는 커널 사용자 통신에 ctl_enqueuedata를 사용하고 있습니다.Ost 커널 크래시 (ctl_enqueuedata 내부)

은 가끔 (정말 그것을 재현 할 수없는) 알 - 내가 디버거를 사용하여 연결하면 내가 ctl_enqueuedata

의 내부 충돌을 가지고, 역 추적이있는 것 같다

frame #0: 0xffffff80248bcecb mach_kernel`Debugger(message=<unavailable>) + 555 at model_dep.c:912 
frame #1: 0xffffff802481d636 mach_kernel`panic(str=<unavailable>) + 198 at debug.c:336 
frame #2: 0xffffff8024b4e45f mach_kernel`kauth_cred_unref_hashlocked(credp=0xffffff8035ca0d58) + 47 at kern_credential.c:4470 
frame #3: 0xffffff8024b4cf7d mach_kernel`kauth_cred_unref(credp=<unavailable>) + 29 at kern_credential.c:4521 
* frame #4: 0xffffff8024b9e585 mach_kernel`sodealloc(so=0xffffff8035ca0b80) + 21 at uipc_socket.c:710 
frame #5: 0xffffff8024b59942 mach_kernel`ctl_unlock [inlined] ctl_sofreelastref + 354 at kern_control.c:263 
frame #6: 0xffffff8024b598be mach_kernel`ctl_unlock(so=<unavailable>, refcount=<unavailable>, lr=<unavailable>) + 222 at kern_control.c:1076 
frame #7: 0xffffff8024b58ebd mach_kernel`ctl_enqueuedata(kctlref=<unavailable>, unit=<unavailable>, data=<unavailable>, len=<unavailable>, flags=<unavailable>) + 301 at kern_control.c:549 
frame #8: 0xffffff7fa6090efd

을 다음 소켓 자격 증명이 0입니다.

어떻게 될 수 있습니다. 커널 버그입니까, 아니면 ctl_enqueuedata를 오용합니까?

출처

2014-03-27 Georgy Buranov

이 추적에서 이상한 점은 ctl_enqueuedata 끝에 소켓 (sodealloc)이 파괴되고 있다는 것입니다. 이것은 정상적인 작동에서 기대할 수있는 것이 아닙니다.

소켓의 ctl_disconnect_func/ctl_disconnect 콜백 사이에 경쟁 조건이 있고 ctl_enqueuedata()을 호출 할 수 있습니까? 연결 해제 콜백이 발생하면 새로운 데이터가 대기열에 들어 가지 않도록해야합니다. 또한 연결 해제 콜백에서 반환 할 때까지 모든 대기열 작업이 완료되었는지 확인해야합니다. 실제로 이것은 엔큐하는 동안 잠금을 유지하고 연결을 해제 할 때 데이터 구조를 변경하는 동안 잠금에서 잠금을 획득해야 함을 의미합니다.

분명히 문제가 아닌 것으로 확인 된 경우 : 어떤 커널 버전입니까? 라인 번호를 제대로 조정하는 데 어려움을 겪고 있습니다.

출처

2014-03-29 05:29:55 pmdj

예! 또한 클라이언트가 연결을 끊고 커널이 그 시점에 ctl_enqueuedata를 사용하여 데이터를 보내고 있다고 생각합니다. 하지만 ctl_disconnect_func에서 lck_rw_lock_exclusive (dlist.read_write_lock)를 사용하고 ctl_enqueuedata 전에 lck_shared_lock을 사용하여 잠금을 만들려고했습니다. –

정말 작동하는지 모르겠지만 https://developer.apple.com/library/mac/documentation/Kernel/Reference/kern_control_header_reference/Reference/reference.html 도움이 "ctl_disconnect_func는 수신하는 데 사용됩니다. 클라이언트가 커널 컨트롤에서 연결이 끊겼다는 알림. " 이것이 맞다면 잠금이 도움이되지 않습니다 - 클라이언트는 이미 연결이 끊어져 있습니다. 우리는 방금 그것에 대해 통지를 받았습니다 –

또한, 사용자 공간 프로세스가 방금 충돌했을 때 어떻게 될 것입니까? (그것은 나의 경우에도 가능하다). 이 경우 ctl_disconnect_func에 어떤 종류의 잠금이 있어도 사용자 공간이 존재하지 않습니다 –

Ost 커널 크래시 (ctl_enqueuedata 내부)

답변

관련 문제