Kernel crash w/o reason

[Jan Engelhardt]

>1) In kmi_fops.d_open():
>|    if(!mtx_trylock(&Open_lock)) { return EBUSY; }
>|    return 0;
>
>this can not work. You cannot return to userland with a lock acquired.

So? The full code also contains a uio_read() function. If I release the 
lock in uio_read(), no crash happens. It's just in uio_close().

Why can't I hold this lock, as it is possible with Linux? A mutex is basically 
just an atomic counter AFAIK, and if nobody releases it in-between, it is 
still held by the time we enter uio_close() - thus it could be unlocked 
without problems. In theory at least.

What should I use instead? A semaphore?

>2) If you report a problem, try to provide an error message. In this case a 
>crashdump/panic string. When you do kernel programming you should always run 
>in a debug kernel. To debug this specific problem WITNESS is helpful.

I've tracked it a little and found out that it is mtx_unlock() which crashes, 
or more precisely, it is line
	td1 = turnstile_head(ts)
in _mtx_unlock_sleep() -- ts == NULL! I have dug deep into &m->mtx_object and 
it looks like the TC list (in turnstile_lookup) is empty, but I do not know 
why.

>4) Why on earth do you use gmake? What's wrong with bsd.*.mk? It's a whole lot 
>easier.

Because non-BSD (read: Linux, MINGW/MSYS and Cygwin) do not ship BSD make. And 
of course, that I got to GNU make first and had few joy to learn another make 
syntax.



Jan Engelhardt
-- 
ENOSPC