Kext вызывает панику в потоке переключения контекста в macOS 10.14.

Question

Недавно я тестировал свой 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 у меня нет доступа к этому регистру, и я сомневаюсь, что он сопоставлен с моей памятью драйвера.

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

Спасибо

Answer 1

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

register read

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