Kext вызывает панику при переключении контекста потока в macOS 10.14. - PullRequest
0 голосов
/ 13 июня 2018

Недавно я протестировал свой kext на 10.14, и какое-то время он работал нормально.Но после некоторого случайного времени (может занять несколько минут), он вызывает следующую панику:

thread_invoke: preemption_level -1, possible cause: unlocking an
unlocked mutex or spinlock"

Это я запускал свой код несколько раз и заметил, что паника может быть вызвана любым моим пользователем.Космический демон при вызове psynch_cvwait sys или непосредственно из расширения ядра при запуске переключения контекста после вызова msleep функции.

Вот трассировка от ядра:

frame #4: 0xffffff800afe24a3 kernel`panic(str=<unavailable>) at debug.c:620 [opt]
frame #5: 0xffffff800affef06 kernel`thread_invoke(self=0xffffff801b7a4030, thread=0xffffff801afe4540, reason=0) at sched_prim.c:2261 [opt]
frame #6: 0xffffff800affdaff kernel`thread_block_reason(continuation=<unavailable>, parameter=<unavailable>, reason=<unavailable>) at sched_prim.c:3088 [opt]
frame #7: 0xffffff800b4fcfe1 kernel`_sleep [inlined] thread_block(continuation=<unavailable>) at sched_prim.c:3104 [opt]
frame #8: 0xffffff800b4fcfd6 kernel`_sleep(chan=<unavailable>, pri=0, wmsg=<unavailable>, abstime=1299691844730, continuation=0x0000000000000000, mtx=0x0000000000000000) at kern_synch.c:251 [opt]
frame #9: 0xffffff800b4fd352 kernel`msleep(chan=0x01000004001ddd89, mtx=0x0000000000000000, pri=0, wmsg="", ts=<unavailable>) at kern_synch.c:346 [opt]

И следующая трассировка стека, запущенная из вызова sys демона пользовательского пространства:

frame #4: 0xffffff800afe24a3 kernel`panic(str=<unavailable>) at debug.c:620 [opt]
frame #5: 0xffffff800affef06 kernel`thread_invoke(self=0xffffff80176f5a50, thread=0xffffff8019a5de60, reason=0) at sched_prim.c:2261 [opt]
frame #6: 0xffffff800affdaff kernel`thread_block_reason(continuation=<unavailable>, parameter=<unavailable>, reason=<unavailable>) at sched_prim.c:3088 [opt]
frame #7: 0xffffff7f8cbf5080
frame #8: 0xffffff7f8cbf6dcf
frame #9: 0xffffff800b499c3c kernel`psynch_cvwait(p=<unavailable>, uap=<unavailable>, retval=<unavailable>) at pthread_shims.c:397 [opt]

, где отсутствуеткадры принадлежат расширению com.apple.kec.pthread(1.0)[C69B97C1-505D-3629-9D64-7B7BC6D780A8]@0xffffff7f8cbf3000->0xffffff7f8cbfafff

Сначала я подумал, что это может быть вызвано случайным повреждением памяти, но похоже, что после всех моих репродукций никакая другая сущность, кроме двух, которые я только что упомянул, не вызвала панику.

Если я посмотрю на сообщение о панике, оно связано со значением, которое можно найти в регистре% gs на процессор, где сохраняется уровень приоритетности.Тем не менее, в lldb у меня нет доступа к этому регистру, и я сомневаюсь, что он сопоставлен с моей памятью драйвера.

Итак, я оставил комментарии к частям моего драйвера и проверил, сохраняется ли проблема ..Возможно, у кого-то из вас есть больше идей о том, как решить эту проблему?

спасибо

1 Ответ

0 голосов
/ 13 июня 2018

Я полагаю, что следующая команда lldb должна напечатать регистр gs вместе со всеми остальными:

register read

Раньше я только сталкивался с этой паникой, когда имел дело со спин-блокировками, поскольку они отключали вытеснение.Если ваш kext не использует спин-блокировки и явно не отключает вытеснение через встроенную сборку, это, вероятно, ошибка в macOS, и я бы сообщил об этом Apple ASAP.

...