From owner-freebsd-arch Fri Mar 29 20:12:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 7765237B400; Fri, 29 Mar 2002 20:12:16 -0800 (PST) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g2U4CCw74331; Fri, 29 Mar 2002 23:12:12 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Fri, 29 Mar 2002 23:12:12 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: John Baldwin Cc: arch@FreeBSD.org Subject: Re: curthread vs. passing thread pointers around In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 29 Mar 2002, John Baldwin wrote: > During a discussion on the smp@ list about changes to the suser() API > to make use of td_ucred, it was brought up that the new suser() would > be assuming that the passed in thread pointer was curthread so why not > just use curthread in suser() and not pass in a pointer at all. There > are several places in the kernel where the same assumption is made. > Thus, my question is: which general approach should we follow, and > should we perhaps switch to using explicit curthread's everywhere and > stop passing thread pointers around on the stack? There are a number of situations which are rather sticky involving credentials and VFS. Basically, the set of relevant credentials is often two or three different credentials (especially for filesystems like procfs). Typically there's a cached credential associated with a persistent data naming abstraction (sich as the struct file pointing at a socket or vnode), as well as the active requesting credential. This means that low-level access control primitives almost always need to accept an explicit credential reference, although higher level primitives might make assumptions about the source of the credential. In the file system and specfs code, I've seen both the explicit VFS credential (usually sourced from a struct file, although not always), and the active requesting credential used. Frequently, incorrectly, actually. For example, there are a number of places where the cached credential is used and really should not be; likewise, there are a number of places where incorrect assumptions may be made about credentials belonging to curproc/thread. For VFS, which is a special case, I'd actually like to see both credentials passed down the stack explicitly, meaning that worker threads and processes in kernel don't have to tweak their active credential in order to make a request on behalf of another thread or process (think async io, async nfs rpc activities, etc). This actually suggests a model something like... vop_foo(vp, ..., cachedcred, activecred); for almost all VOP's. For many other simpler non-VFS/socket/... cases, moving to implicit curthread-derived credentials is probably the right choice, as it limits the exposure of specific structures in code that doesn't care about the structures. Even if we don't move to using curthread (for performance or other reasons), we should be making *extremely* heavy use of KASSERT(). Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message