From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 11 20:22:45 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 B2D491065676 for ; Mon, 11 Jan 2010 20:22:45 +0000 (UTC) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.10]) by mx1.freebsd.org (Postfix) with ESMTP id 4C45B8FC22 for ; Mon, 11 Jan 2010 20:22:45 +0000 (UTC) Received: from vampire.homelinux.org (dslb-088-066-024-221.pools.arcor-ip.net [88.66.24.221]) by mrelayeu.kundenserver.de (node=mrbap2) with ESMTP (Nemesis) id 0MJEQE-1NRftm0Jqc-002xjU; Mon, 11 Jan 2010 21:22:44 +0100 Received: (qmail 70266 invoked from network); 11 Jan 2010 20:22:43 -0000 Received: from f8x64.laiers.local (192.168.4.188) by laiers.local with SMTP; 11 Jan 2010 20:22:43 -0000 From: Max Laier Organization: FreeBSD To: freebsd-hackers@freebsd.org Date: Mon, 11 Jan 2010 21:22:42 +0100 User-Agent: KMail/1.12.4 (FreeBSD/8.0-RELEASE-p2; KDE/4.3.4; amd64; ; ) References: <4B4B7A7F.2090808@sepehrs.com> In-Reply-To: <4B4B7A7F.2090808@sepehrs.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201001112122.43000.max@love2party.net> X-Provags-ID: V01U2FsdGVkX18b+OOHGjlzPcw9OsWDJ6CT6SaojFAFfWpDiXh 3LF9rf63t+v6cxVPbXAHDHnaw2igrpmCatDVISM7WvEurPZL+e pXMGCusY7mc0rXJ9rj+yw== Cc: "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: Mon, 11 Jan 2010 20:22:45 -0000 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); -- Max