uiomove and mutex

[Xin LI]

On Mon, Jan 11, 2010 at 11:22 AM, H.Fazaeli <fazaeli at 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.  No 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 = 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,
-- 
Xin LI <delphij at delphij.net> http://www.delphij.net