From owner-freebsd-arch Sun Nov 11 7:32: 8 2001 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 C19DD37B41F for ; Sun, 11 Nov 2001 07:32:03 -0800 (PST) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.5) with SMTP id fABFVsB11812 for ; Sun, 11 Nov 2001 10:31:55 -0500 (EST) (envelope-from robert@fledge.watson.org) Date: Sun, 11 Nov 2001 10:31:54 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org To: freebsd-arch@FreeBSD.org Subject: cur{thread/proc}, or not. 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 Every now and then, we get to discuss curproc, and its merits. Let's do it again. There are a number of uses of curproc in the netinet code, used to retrieve credentials for authorization somewhere down the stack, when no proc or thread pointer has been passed down. With the eventual addition of td->td_ucred, it will be desirable to use the credential for the current thread, rather than the proc, which will require locking to use. (This is, incidentally, true of many places in the system). As I understand it, use of curproc was branded 'undesirable' at some point in the semi-distant past, and since that time, a reference to 'proc' has been passed down the stack. With a change to KSE, this has been translated to references the thread, but the issue remains the same. This comes up in particular because I have a tree where I have propagated the thread pointer down if_ioctl in the network stack: the normal ioctl call carries a thread pointer now, but when it is translated into if_ioctl by the network stack, that pointer is lost. This raises the question: should we (in practice) be adding process or thread pointers to many more of the function arguments, or should we switch to using curproc/curthread instead. The argument I've seen a couple of times for using the proc/thread pointer is that of delegation: a kernel thread might be acting on behalf of another process, and need a reference to the process so that it can use its (file descriptors, credential, address space, ...). I suspect that, in practice, this is a Bad Idea, given the increased complexity of fine-grained threading/locking and SMPng. "borrowing" references in such an environment seems like a recipe for buginess, and instead such references should be "given" by the thread that obeys the locking/reference counting, and should not be done at the level of the proc. For example, for a credential, you would simply grab another reference to the credential and pass off the reference, rather than sharing a reference. In fact, it seems that in a lot of places where a struct proc is passed in, the implicit assumption of the code is that this is the "current process", and as we add more process-related locking, that assumption will probably only grow stronger, so as to not raise lock order issues. I don't pretend to have a grasp of all the issues here, so the purpose of this message is to raise the issues so that I can understand them. I have a tree where I've eliminated many references to curproc; however, I'm now wondering if it wouldn't simply be more useful to eliminate many of the references to struct proc in the function arguments, and use curproc instead, and add references to ucred (and related ref-counted structures) as needed for delegation types of situations. In particular, that would suggest the following changes: (1) 'suser' would always use 'curthread', and lose its proc/thread argument (proc in the main tree, thread in my tree). 'suser_cred' would be used for delegation situations (as is the case in my tree). (Note that this remains incompatible with other platforms, which generally accept a cred argument for 'suser', including other *BSD and Solaris.) (2) proc/thread arguments would (in general) be removed (gradually) from the arguments of many existing kernel functions, and 'curproc'/'curthread' would be used instead. For example, in the 'VOP_*' interface, use of the 'p' or 'td' entries would be abandoned, and 'cred' would be more widely passed down (such as into open). (Note that this is the path taken by a number of other fine-grained UNIX kernels, including Solaris, IRIX, et al). (3) Use of 'curproc' would be removed in a number of places, where abstracted functions such as 'suser' would invoke curthread instead. It seems to me that unless a very strong argument exists against using curproc/curthread (and I don't preclude one existing), using them would actually be an improvement, as it would assert that this class of 'borrowing' couldn't exist, simplifying the kernel, not to mention squeezing a bit more stuff out of the stack (which, at ten levels deep, actually begins to add up on 64-bit machines). I believe that there are many places where the 'p' passed in is implicitly assumed to be the current process, and that making that reliance explicit would be an improvement, rather than a problem. Flames appreciated. 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