Date: Fri, 08 Dec 2000 09:38:47 -0800 From: Kirk McKusick <mckusick@mckusick.com> To: Alfred Perlstein <bright@wintelcom.net> Cc: Terry Lambert <tlambert@primenet.com>, arch@FreeBSD.ORG Subject: Re: Getting Kernel Process Information Message-ID: <200012081738.JAA04933@beastie.mckusick.com> In-Reply-To: Your message of "Thu, 07 Dec 2000 19:39:32 PST." <20001207193932.F16205@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Date: Thu, 7 Dec 2000 19:39:32 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Terry Lambert <tlambert@primenet.com> Cc: Kirk McKusick <mckusick@mckusick.com>, arch@FreeBSD.ORG Subject: Re: Getting Kernel Process Information * Terry Lambert <tlambert@primenet.com> [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." We already use sysctl to get the proc information out of the kernel. The traversal of the proc entry to gather up the information is done in kern/kern_proc.c function fill_kinfo_proc. So, any and all locking that needs to be done can be done there. The libkvm code uses sysctl to get the desired proc entries when running on a live system. It also knows how to grub through a crash dump to essentially duplicate the fill_kinfo_proc, but that is not intended to be used on live kernels. Kirk 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?200012081738.JAA04933>