From owner-freebsd-current Thu Feb 7 20: 3:39 2002 Delivered-To: freebsd-current@freebsd.org Received: from mail6.speakeasy.net (mail6.speakeasy.net [216.254.0.206]) by hub.freebsd.org (Postfix) with ESMTP id 1CBBD37B419 for ; Thu, 7 Feb 2002 20:03:31 -0800 (PST) Received: (qmail 2309 invoked from network); 8 Feb 2002 04:03:29 -0000 Received: from unknown (HELO laptop.baldwin.cx) ([65.91.155.186]) (envelope-sender ) by mail6.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 8 Feb 2002 04:03:29 -0000 Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 07 Feb 2002 23:03:27 -0500 (EST) From: John Baldwin To: Julian Elischer Subject: RE: ucred for threads Cc: current@freebsd.org 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 08-Feb-02 Julian Elischer wrote: > > As part of the KSe stuff I ended up changing ht ebehaviour of threads with > respect to their ucreds. Previously, they freed their ucred reference when > they entered user space and picked them up again when they re-entered the > kernel. It there was an AST then they re-loaded teh already freed ucred to > perform the AST. (and then freed it again, (For each AST). > Since each 'get' and free required a lock and unlock of the proc > structure, this meant that there were at least 2 locks and 2 unlocks, and > possibly many more, for the average kernel entry/exit pair. > > Since the chance that the ucred on the next entry is not the same as the > thread already had on it's last kernel exit, is almiost negligible, > it makes sence to hold the ucred acress the user period an dsimply check > it agains the process's ucred on th enext entry. > > In the KSE code I have: > in trap(), and syscall() > > if (td->td_ucred != p->p_ucred) { > PROC_LOCK(p); > if (td->td_ucred) { > crfree(td->td_ucred); > td->td_ucred = NULL; > } > if (p->p_ucred != NULL) { > td->td_ucred = crhold(p->p_ucred); > } > PROC_UNLOCK(p); > } > > > THis is actually not dependent on KSE (though I originally needed it > for KSE I have since decided that it would be a good idea anyhow). > > Do those who deal in ucreds (probably jhb and Robert W) > agree or disagree.. (if so I'll happily commit it as it shrinks the KSE > patches a bit more :-) 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. -- 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