panic by unlocking of mutex in KLD

[Mateusz Guzik]

On Mon, Jan 12, 2009 at 07:16:51PM +0100, Alexej Sokolov wrote:
> 2009/1/12 Mateusz Guzik <mjguzik at gmail.com>
> 
> > On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote:
> > > 2009/1/12 Mateusz Guzik <mjguzik at gmail.com>
> > > > Mutexes have owners. It panics on loading because processes cannot
> > > > return to userland with locks held.
> > >
> > > i am not sure about it. Some time ago i implemented a charecter device
> > with
> > > two syscalls: write, read. "write" lock the mutex and  "read" unlock it.
> > The
> > > user space programm opens device, then mekes "write" (mutex will held in
> > > kernel), goes back to user space, then makes "read" (mutex will unlocked
> > in
> > > kernel) and it all run without panic. If needed i can post the source
> > code.
> > >
> >
> > Do you have kernel compiled with WITNESS? At least on -CURRENT the
> > kernel panicked like this (while loading your module):
> >
> > System call kldload returning with 1 locks held
> 
> My kernel is compiled without WITNESS. And it allows to lock mutex in one
> systcall (for example "write") and to unlock it in other ("read").
> Do you mean it is "very bad idea" to do something like this ?
> I could not find anywhere in the documentation that a it is not allowed to
> return in the user space with a locked mutex.
> Can you give me some reference on man page, source code or something other
> from where can I understand it ?
> 

Locks are used to synchronize access to data changeable by other
threads. I don't know if I'm correct here, but let's consider the
following situation: your process grabs a mutex and returns to userland,
then it's killed due to segmentation violation. This mutex should (and
can be) unlocked on exit, but the state of data protected by it is
unknown. (For example your process was killed while inserting something
into linked list.) So even if the kernel could be guided to unlock it on
exit, the data could be in inconsistent state.

Also your locking scheme doesn't make much sense. Consider this:
	proc1 calls write on your cdev
but in the meantime
	proc2 calls read on your cdev

So you get panic because proc1 was writing some data. (attempt to unlock
mutex locked by proc1) Even if the kernel wouldn't panic, proc2 would
read inconsistend data because proc1 was writing. Proper solution is to
lock mutex before and after reading/writing data. For working example
you can check how devctl was implemented (sys/kern/subr_bus.c).

-- 
Mateusz Guzik <mjguzik at gmail.com>