Re: Detecting threads vs processes with ps or /proc

[Albert D. Cahalan]

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.