From owner-freebsd-arch Wed Apr 4 9:53:40 2001 Delivered-To: freebsd-arch@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id 180D037B725; Wed, 4 Apr 2001 09:53:39 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.2/8.9.3) id f34GrX188215; Wed, 4 Apr 2001 09:53:33 -0700 (PDT) (envelope-from dillon) Date: Wed, 4 Apr 2001 09:53:33 -0700 (PDT) From: Matt Dillon Message-Id: <200104041653.f34GrX188215@earth.backplane.com> To: Robert Watson Cc: Alfred Perlstein , Brian Somers , freebsd-arch@FreeBSD.ORG Subject: Re: Eliminate crget() from nfs kernel code? References: Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :For those interested in giving the p->p_ucred version a try, the simply :patch is below. It works between FreeBSD boxes, and my tests against :Solaris 5.5. Unfortunately, my remote NFS test box already has interop :problems with Linux due to the new mount_nfs that I haven't applied :patches to yet, so I can't test that case. : :Robert N M Watson FreeBSD Core Team, TrustedBSD Project :robert@fledge.watson.org NAI Labs, Safeport Network Services It occurs to me that we may have a general problem with p->p_ucred here. For KSEs to work, processes will not be able to assume that they 'own' p->p_ucred if/when they block. What happens if one thread is blocked in a system call that is using p->p_ucred directly without bumping its ref count and another thread goes in and changes the cred? -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message