title: Kext trigger panic in thread context switch in macOS 10.14.
body: <p>Recently, I've tested my kext on 10.14 and it seem to run smoothly for a while. But after some random time(can take few minutes), It produces the following panic : </p>
  
  <pre><code>thread_invoke: preemption_level -1, possible cause: unlocking an
  unlocked mutex or spinlock"
  </code></pre>
  
  <p>This I've ran my code several times and have noticed that the panic may be triggered by either my user-space daemon while calling <code>psynch_cvwait</code> sys call or directly from the kernel extension while triggering context switch after calling <code>msleep</code> function. </p>
  
  <p>Here's a trace from the kernel :</p>
  
  <pre><code>frame #4: 0xffffff800afe24a3 kernel`panic(str=&lt;unavailable&gt;) 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=&lt;unavailable&gt;, parameter=&lt;unavailable&gt;, reason=&lt;unavailable&gt;) at sched_prim.c:3088 [opt]
  frame #7: 0xffffff800b4fcfe1 kernel`_sleep [inlined] thread_block(continuation=&lt;unavailable&gt;) at sched_prim.c:3104 [opt]
  frame #8: 0xffffff800b4fcfd6 kernel`_sleep(chan=&lt;unavailable&gt;, pri=0, wmsg=&lt;unavailable&gt;, 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=&lt;unavailable&gt;) at kern_synch.c:346 [opt]
  </code></pre>
  
  <p>And next is a stack trace triggered from the user-space daemon sys call:</p>
  
  <pre><code>frame #4: 0xffffff800afe24a3 kernel`panic(str=&lt;unavailable&gt;) 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=&lt;unavailable&gt;, parameter=&lt;unavailable&gt;, reason=&lt;unavailable&gt;) at sched_prim.c:3088 [opt]
  frame #7: 0xffffff7f8cbf5080
  frame #8: 0xffffff7f8cbf6dcf
  frame #9: 0xffffff800b499c3c kernel`psynch_cvwait(p=&lt;unavailable&gt;, uap=&lt;unavailable&gt;, retval=&lt;unavailable&gt;) at pthread_shims.c:397 [opt]
  </code></pre>
  
  <p>where the missing frames belongs to extension <code>com.apple.kec.pthread(1.0)[C69B97C1-505D-3629-9D64-7B7BC6D780A8]@0xffffff7f8cbf3000-&gt;0xffffff7f8cbfafff</code> </p>
  
  <p>At first I thought it might be caused from random memory corruption, but it looks that after all my reproductions, no other entity besides the 2 I just mentioned triggered the panic.</p>
  
  <p>If I look at the panic message, it connected to value that may be found in %gs register per processor, where the preemption level is kept. However, in lldb I don't have any access to this register and I doubt if it's mapped to my driver memory.</p>
  
  <p>So what I left is to comments parts of my driver and see if the problem persists.. Perhaps any of you have more insights about how to address this problem ? </p>
  
  <p>thanks</p>