From owner-freebsd-current@FreeBSD.ORG Tue Dec 20 20:54:52 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E142B1065672; Tue, 20 Dec 2011 20:54:52 +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 B354E8FC19; Tue, 20 Dec 2011 20:54:52 +0000 (UTC) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [96.47.65.170]) by cyrus.watson.org (Postfix) with ESMTPSA id 5005346B0D; Tue, 20 Dec 2011 15:54:52 -0500 (EST) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id CB180B91A; Tue, 20 Dec 2011 15:54:51 -0500 (EST) From: John Baldwin To: Gleb Smirnoff Date: Tue, 20 Dec 2011 15:54:51 -0500 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p8; KDE/4.5.5; amd64; ; ) References: <261812530.427572.1324344105125.JavaMail.root@erie.cs.uoguelph.ca> <201112200900.39087.jhb@freebsd.org> <20111220193139.GD70684@FreeBSD.org> In-Reply-To: <20111220193139.GD70684@FreeBSD.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201112201554.51120.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Tue, 20 Dec 2011 15:54:51 -0500 (EST) Cc: freebsd-current@freebsd.org, Rick Macklem Subject: Re: making crdup()/crcopy() safe?? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 20:54:53 -0000 On Tuesday, December 20, 2011 2:31:40 pm Gleb Smirnoff wrote: > John, > > On Tue, Dec 20, 2011 at 09:00:39AM -0500, John Baldwin wrote: > J> In general the caller of crdup is expected to hold a reference on cred or some > J> other lock to ensure that cred remains valid and cannot be free'd while it is > J> being duplicated. There is no global lock that crdup can hold for that, > J> instead the caller is required to guarantee that. > > I already noticed to Rick in a private email, that there is suspisious > place in new NFS, where newly allocated (via crdup) cred is temporarily > placed on td_ucred, and then removed at the end of function. The function > may sleep in malloc() and also block on mutexes. None of that matters. Only curthread touches td_ucred. It isn't going to free its own credential while it is asleep. :) > I suspect, that it may happen, that some other kernel facility performs > crfree(td->td_ucred), and later on we are using already freed cred. > > However, I can't imagine which facility may do this. What if process gets > SIGKILL while its thread is blocked on mutex or sleeping? Would it > be reaped after it yields or before? No, a signal is merely marked as pending. It isn't delivered to a thread in the kernel until it exits back out of the kernel and prepares to return to userland (e.g. in userret()). Only at that time will the thread actually be killed. -- John Baldwin