From owner-freebsd-hackers@FreeBSD.ORG Mon Jan 11 20:11:19 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 8EC211065676 for ; Mon, 11 Jan 2010 20:11:19 +0000 (UTC) (envelope-from delphij@gmail.com) Received: from mail-px0-f182.google.com (mail-px0-f182.google.com [209.85.216.182]) by mx1.freebsd.org (Postfix) with ESMTP id 612F68FC15 for ; Mon, 11 Jan 2010 20:11:18 +0000 (UTC) Received: by pxi12 with SMTP id 12so14759843pxi.3 for ; Mon, 11 Jan 2010 12:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=PHGBtmxKmiLasGJi4ti2aMkhFTRiHzWtE09rnVe7WjQ=; b=ih2NZaDW2McXGhpKHpzwpolRoQMbyi31O2afBrrcqja4fKFNc+8P/8wL2Ihvga0mGY FSHpbX6Llzuuoyf1yQVdRxpYaeK0p9YQ/Kpzqu4dm3mdYTsdQc2Nl4JTq3e3WCP+NApP RzjreNfo5EEvCW9MGzBqyEScxwZFpjramQy0Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Enwxg24uuru2dW20dPPIGAA3Z2CNHH5QOnavGU86EVVAqXSoITonCujO/ZpoSIhrmp 2CHS+mhTlKBlMHddbuhltmkqfQPDmaP9+T7e5kE9wi9XksFg171A0tUecgwpXmP6QlOK /HMqz+dg0rUutnJdRBackHeMnvii86hH120ao= MIME-Version: 1.0 Received: by 10.114.18.37 with SMTP id 37mr460118war.143.1263240676252; Mon, 11 Jan 2010 12:11:16 -0800 (PST) In-Reply-To: <4B4B7A7F.2090808@sepehrs.com> References: <4B4B7A7F.2090808@sepehrs.com> Date: Mon, 11 Jan 2010 12:11:16 -0800 Message-ID: From: Xin LI To: "H.Fazaeli" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org 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:11:19 -0000 On Mon, Jan 11, 2010 at 11:22 AM, 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. =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 http://www.delphij.net