From owner-freebsd-arch Thu Dec 7 19:39:39 2000 From owner-freebsd-arch@FreeBSD.ORG Thu Dec 7 19:39:36 2000 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 9D07637B402 for ; Thu, 7 Dec 2000 19:39:34 -0800 (PST) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id eB83dWV29351; Thu, 7 Dec 2000 19:39:32 -0800 (PST) Date: Thu, 7 Dec 2000 19:39:32 -0800 From: Alfred Perlstein To: Terry Lambert Cc: Kirk McKusick , arch@FreeBSD.ORG Subject: Re: Getting Kernel Process Information Message-ID: <20001207193932.F16205@fw.wintelcom.net> References: <20001207115616.V16205@fw.wintelcom.net> <200012080335.UAA02960@usr08.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200012080335.UAA02960@usr08.primenet.com>; from tlambert@primenet.com on Fri, Dec 08, 2000 at 03:35:26AM +0000 Sender: bright@fw.wintelcom.net Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Terry Lambert [001207 19:35] wrote: > [ ... reorg of proc structure to keep it from being a PITA ... ] > > > I completely agree that should be done. My suggestion is to > > completely rip out and kernel structs being passed through > > this interface, the reason is that we will need mutexes in > > a lot of them and we don't want to export that to userland. > > Let me remind you that copying data out of /dev/kmem into user > space from structures like this is inherenetly MP-unsafe. > > Without holding the mutex, you can not guarantee that the > structure contents will not change out from under the user > space process while it is in the middle of copying them out. > > Ignoring the obvious things, like divide-by-zero errors, this > is mostly a problem for programs trying to do list traversal, > as opposed to particular data objects (unless they contain > pointers themselves). > > Right now, the BGL protects us from this. > > Please do not build a soloution which will not work on MP > systems, once the BGL is removed. I agree with you, however Kirk's idea doesn't make this impossible, we can later have a sysctl that (for this case) looks up and locks the proc then copies it out in eproc (or whatever it's called) format with proper locking. One step at a time. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message