From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 12 14:57:09 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 950F51065670 for ; Tue, 12 Jan 2010 14:57:09 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 661648FC13 for ; Tue, 12 Jan 2010 14:57:09 +0000 (UTC) Received: from bigwig.baldwin.cx (66.111.2.69.static.nyinternet.net [66.111.2.69]) by cyrus.watson.org (Postfix) with ESMTPSA id 13DE146B52; Tue, 12 Jan 2010 09:57:09 -0500 (EST) Received: from jhbbsd.localnet (smtp.hudson-trading.com [209.249.190.9]) by bigwig.baldwin.cx (Postfix) with ESMTPA id 7AE298A01D; Tue, 12 Jan 2010 09:56:56 -0500 (EST) From: John Baldwin To: freebsd-hackers@freebsd.org Date: Tue, 12 Jan 2010 08:14:08 -0500 User-Agent: KMail/1.12.1 (FreeBSD/7.2-CBSD-20091231; KDE/4.3.1; amd64; ; ) References: <4B4B7A7F.2090808@sepehrs.com> <201001112122.43000.max@love2party.net> In-Reply-To: <201001112122.43000.max@love2party.net> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001120814.08397.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0.1 (bigwig.baldwin.cx); Tue, 12 Jan 2010 09:56:56 -0500 (EST) X-Virus-Scanned: clamav-milter 0.95.1 at bigwig.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.6 required=4.2 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on bigwig.baldwin.cx Cc: Max Laier , "H.Fazaeli" Subject: Re: uiomove and mutex X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2010 14:57:09 -0000 On Monday 11 January 2010 3:22:42 pm Max Laier wrote: > On Monday 11 January 2010 20:22:39 H.Fazaeli 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? > > Any memory access to user memory (unless the memory has been wired down > before) can result in a swap in from secondary storage, which - in turn - > results in a sleep. Most locks are not allowed to be held over a sleep. > > See locking(9) for details. > > > 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? > > sx(9) is one possibility. The other way is to use a pointer or state that you > modify while holding the mutex: > > Thread1: > > lock(&mtx); > buffer_in_use=1; > unlock(&mtx); > > uiomove() > > lock(&mtx); > buffer_in_use=0; > wakeup(&buffer_in_use); > unlock(&mtx); > > Thread2: > > lock(&mtx); > while(buffer_in_use) > mlseep(&buffer_in_use, &mtx, ...) > do_stuff_to_the_buffer(); > unlock(&mtx); Note that a simple flag like this is actually a slower version of using an sx lock. If you have a very simple driver I would just use an sx lock. If you later find that you need to optimize it then you can look at doing something fancier. If you already have other state you are frobbing that includes the equivalent of a buffer_in_use flag then an approach like the above may be ok instead of an sx lock. -- John Baldwin