From owner-freebsd-current Mon Feb 11 19: 9:20 2002 Delivered-To: freebsd-current@freebsd.org Received: from newman2.bestweb.net (newman2.bestweb.net [209.94.102.67]) by hub.freebsd.org (Postfix) with ESMTP id 0613037B438; Mon, 11 Feb 2002 18:17:18 -0800 (PST) Received: from okeeffe.bestweb.net (okeefe.bestweb.net [209.94.100.110]) by newman2.bestweb.net (Postfix) with ESMTP id 19E692327D; Mon, 11 Feb 2002 21:16:53 -0500 (EST) Received: by okeeffe.bestweb.net (Postfix, from userid 0) id 33B129EFB2; Mon, 11 Feb 2002 21:11:58 -0500 (EST) Date: Thu, 7 Feb 2002 20:43:36 -0800 (PST) From: Julian Elischer To: John Baldwin Cc: current@freebsd.org Subject: RE: ucred for threads Message-Id: <20020212021158.33B129EFB2@okeeffe.bestweb.net> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, 7 Feb 2002, John Baldwin wrote: > > > This code is not safe on SMP non-i386 machines (i.e. ia64, sparc64, alpha, and > possibly p3 and later i386's) because the p_ucred value you read could easily > be a stale value, thus rendering the test invalid. You need the lock for the > compare. Conceptually minimizing the crfree's isn't bad I guess. However, the > td_ucred pointer should nto be read if the thread is not in the kernel, and > having it set to NULL when we leave the kernel provides a conveninet way of > ensuring this doesn't happen since we will panic if we do. if the ucred is stale or not is completely unimportant. if you wish to ensure that all your threads get the new ID that you are setting then you need to synchronise them at the program level to ensure teh order in which they enter the kernel on their next system calls. There is no point is sychronising with locks because the threads in question may have run in any order anyhow. > > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message