Date: Mon, 11 Jan 2010 12:11:16 -0800 From: Xin LI <delphij@gmail.com> To: "H.Fazaeli" <fazaeli@sepehrs.com> Cc: freebsd-hackers@freebsd.org Subject: Re: uiomove and mutex Message-ID: <a78074951001111211h5a7a2dcatdf9a884d4b2ffccb@mail.gmail.com> In-Reply-To: <4B4B7A7F.2090808@sepehrs.com> References: <4B4B7A7F.2090808@sepehrs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Jan 11, 2010 at 11:22 AM, H.Fazaeli <fazaeli@sepehrs.com> wrote: > dear gurus > > man mutex(9) states that: > > "No mutexes should be held (except for Giant) across functions which > access memory in userspace, such as copyin(9), copyout(9), uiomove(9), > fuword(9), etc. =C2=A0No locks are needed when calling these functions." > > can someone pls. explain why it is so? These routines MAY yield control. Mutexes should never be held when the calling thread is going to sleep, etc., since they are not supposed to be held for long time, and holding mutex while sleeping may cause deadlock or "livelock" if it has been slept due to someone else sleeping and requires the mutex to be awaken. > Suppose I have a kernel buffer to which kernel writes and > userland processes read via a character device. In the device > read method, If we unlock the mutex just before uiomove, is it > guaranteed that kernel does not write to the buffer in the middle > of uiomove? If yes, how? What is the solution in such a situation? > rwlocks? an intermediate buffer? This really depends on the nature of your operation and there is no generic solution. If the memory block is managed by the driver, it would be probably something like this (just an example to demonstrate the idea): (define a temporary pointer, say p) - hold the mutex - p =3D the block - remove the block from your buffer queue - unhold the mutex - uiomove to userland - hold the mutex - add p back to your buffer queue - unhold mutex However, you can of course find something better than this for situations more specific and avoid some mutex operation... Cheers, --=20 Xin LI <delphij@delphij.net> http://www.delphij.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?a78074951001111211h5a7a2dcatdf9a884d4b2ffccb>