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/