From owner-cvs-all@FreeBSD.ORG Tue Sep 21 03:47:35 2004 Return-Path: Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C235916A4CE; Tue, 21 Sep 2004 03:47:35 +0000 (GMT) Received: from VARK.MIT.EDU (VARK.MIT.EDU [18.95.3.179]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B4EB43D55; Tue, 21 Sep 2004 03:47:35 +0000 (GMT) (envelope-from das@freebsd.org) Received: from VARK.MIT.EDU (localhost [127.0.0.1]) by VARK.MIT.EDU (8.13.1/8.12.10) with ESMTP id i8L3lVqL007598; Mon, 20 Sep 2004 23:47:31 -0400 (EDT) (envelope-from das@freebsd.org) Received: (from das@localhost) by VARK.MIT.EDU (8.13.1/8.12.10/Submit) id i8L3lVnv007597; Mon, 20 Sep 2004 23:47:31 -0400 (EDT) (envelope-from das@freebsd.org) Date: Mon, 20 Sep 2004 23:47:31 -0400 From: David Schultz To: John Baldwin , Julian Elischer , src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org Message-ID: <20040921034731.GA7565@VARK.MIT.EDU> Mail-Followup-To: John Baldwin , Julian Elischer , src-committers@FreeBSD.ORG, cvs-src@FreeBSD.ORG, cvs-all@FreeBSD.ORG References: <200409191834.i8JIYHXU089517@repoman.freebsd.org> <414E0DCA.5090601@elischer.org> <20040920001317.GA2829@VARK.MIT.EDU> <200409201410.58648.jhb@FreeBSD.org> <20040920205940.GA4784@VARK.MIT.EDU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040920205940.GA4784@VARK.MIT.EDU> Subject: Re: cvs commit: src/sys/kern kern_proc.c kern_switch.c src/sys/sys sched.h src/sys/vm vm_glue.c X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Sep 2004 03:47:35 -0000 On Mon, Sep 20, 2004, David Schultz wrote: > BTW, shouldn't PHOLD() assert that (p == curproc)? I think this is > the only race-free way to use it (as opposed to _PHOLD() with the > process already locked). Maybe PHOLD(p) should simply be renamed > PHOLD_CURPROC(). Never mind. It's also safe to PHOLD(uio->uio_td->td_proc), as is done sys/ufs/ffs/ffs_rawread.c. This is because the thread that issued the I/O is known to be sleeping awaiting the I/O completion, so the proc reference must be valid. Not sure what happens with AIO...