Messages in this thread | | | Date | Sun, 8 Dec 2002 19:24:29 -0500 (EST) | From | "Albert D. Cahalan" <> | Subject | Re: Detecting threads vs processes with ps or /proc |
| |
Robert Love writes: > On Fri, 2002-12-06 at 14:56, Nick LeRoy wrote: > >> I was considerring doing something like this as well. From your >> experience, does it work reliably? > > It never fails to detect threads (no false negatives).
Testing the algorithm on idle test processes won't show this damn-obvious race condition:
1. you read the first thread's info 2. the second thread calls mmap() and/or takes a page fault 3. you read the second thread's info
> It does sometimes detect child processes that forked but did not exec as > threads (false positives). The failure case is when a program forks, > does not call exec, and the children go on to execute the exact same > code (so they look and act just like threads, but they have unique > addresses spaces). > > One thing to note: if you can modify the kernel and procps, you can just > export the value of task->mm out of /proc. It is a gross hack, and > perhaps a security issue, but that will work 100%. Same ->mm implies > thread.
This forces sorting, which is slow and eats memory. It's better to list the ->mm peers in a proc file. For example, a /proc/42/mm-peers file containing a simple list of the peers.
There's still a race condition, but at least it only involves threads that get created during the /proc scan.
There's also the problem with new-style threads simply not being listed anywhere. Crackers are going to love it if the Linux 2.6 kernel has a built-in way to hide things. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |