Date: Fri, 29 Mar 2002 23:12:12 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: arch@FreeBSD.org Subject: Re: curthread vs. passing thread pointers around Message-ID: <Pine.NEB.3.96L.1020329230554.73912G-100000@fledge.watson.org> In-Reply-To: <XFMail.20020329143222.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1020329230554.73912G-100000>