Date: Mon, 12 Jan 2009 21:21:53 +0100 From: Mateusz Guzik <mjguzik@gmail.com> To: Alexej Sokolov <bsd.quest@googlemail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: panic by unlocking of mutex in KLD Message-ID: <20090112202152.GC2102@skucha> In-Reply-To: <671bb5fc0901121149m71336fd4k9cfe4b18d41df771@mail.gmail.com> References: <20090112134726.GA2988@debian.samsung.router> <20090112141029.GA31108@skucha> <671bb5fc0901120819q65969961v723807bcb7ad5a96@mail.gmail.com> <20090112173913.GA2102@skucha> <671bb5fc0901121016m7932666cpfe3c089d4c78486e@mail.gmail.com> <20090112192822.GB2102@skucha> <671bb5fc0901121149m71336fd4k9cfe4b18d41df771@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 12, 2009 at 08:49:59PM +0100, Alexej Sokolov wrote: > 2009/1/12 Mateusz Guzik <mjguzik@gmail.com> > > > On Mon, Jan 12, 2009 at 07:16:51PM +0100, Alexej Sokolov wrote: > > > 2009/1/12 Mateusz Guzik <mjguzik@gmail.com> > > > > > > > On Mon, Jan 12, 2009 at 05:19:56PM +0100, Alexej Sokolov wrote: > > > > > 2009/1/12 Mateusz Guzik <mjguzik@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> > > > > Ok , now I understaand it. > If a thread return to user space with locked mutex, kernel doesen't know if > the thread will come back to unlock it. It is really unsafe return to > userspace without unlocking of helding mutexes. > Provided example is really unfortunate. :/ Forget it. (And a proper solution for your locking issue is of course to lock mutex before read/write and *unlock* it after it's done. (missed that word in my previous mail)) Threads in userland holding kernel locks would lead to panics in a lot of situations. For example you already have sleepable mutex and call some kernel function that acquires sx lock - the kernel panics as this is not allowed combination. -- Mateusz Guzik <mjguzik at gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090112202152.GC2102>