Date: Fri, 24 Dec 2004 01:29:27 -0500 From: David Schultz <das@FreeBSD.ORG> To: Jan Engelhardt <jengelh@linux01.gwdg.de> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Kernel crash w/o reason Message-ID: <20041224062927.GA38944@VARK.MIT.EDU> In-Reply-To: <Pine.LNX.4.61.0412232355100.8807@yvahk01.tjqt.qr> References: <Pine.LNX.4.61.0412232230270.11442@yvahk01.tjqt.qr> <200412232307.41735.max@love2party.net> <Pine.LNX.4.61.0412232355100.8807@yvahk01.tjqt.qr>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 24, 2004, Jan Engelhardt wrote:
> >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.
This is not allowed because it can lead to deadlock and other
unsavory situations. Suppose the user process enters an infinite
loop or is waiting for some condition. Now all kernel threads
that attempts to acquire the lock will block. And if any of those
threads have anything to do with the VM system or scheduler or
process exit, then you're really screwed because you won't be able
to kill the process. Although Linux does not explicitly enforce
this correctness condition, it's still wrong to violate it.
> What should I use instead? A semaphore?
You shouldn't have unrelated kernel threads waiting for a user
process at all, so this sounds like a design problem, regardless
of which mutual exclusion primitive you use. (Bear in mind that I
haven't actually looked into what you're trying to do.) In any
case, you can always use mutexes to implement whatever other
synchronization mechanism you need.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20041224062927.GA38944>