Messages in this thread | | | From | David Mosberger <> | Date | Thu, 26 Feb 2004 11:39:21 -0800 | Subject | Re: /proc visibility patch breaks GDB, etc. |
| |
>>>>> On Wed, 25 Feb 2004 22:44:10 -0800, Andrew Morton <akpm@osdl.org> said:
Andrew> Peter Chubb <peter@chubb.wattle.id.au> wrote: >> >> >> In fs/proc/base.c:proc_pid_lookup(), the patch >> >> read_unlock(&tasklist_lock); if (!task) goto out; + if >> (!thread_group_leader(task)) + goto out_drop_task; >> >> inode = proc_pid_make_inode(dir->i_sb, task, PROC_TGID_INO); >> >> means that threads other than the thread group leader don't >> appear in the /proc top-level directory. Programs that are >> informed via pid of events can no longer find the appropriate >> process -- for example, using gdb on a multi-threaded process, or >> profiling using perfmon. >> >> The immediate symptom is GDB saying: Could not open >> /proc/757/status when 757 is a TID not a PID.
Andrew> What does `ls /proc/757' say? Presumably no such file or Andrew> directory? It's fairly bizare behaviour to be able to open Andrew> files which don't exist according to readdir, which is why Andrew> we made that change.
Excuse, but this seems seriously FOOBAR. I understand that it's interesting to see the thread-leader/thread relationship, but surely that's no reason to break backwards compatibility and the ability to look up _any_ task's info via /proc/PID/. A program that only wants to show "processes" (thread-group leaders) can simply read /proc/PID/status and ignore the entries for which Tgid != PPid.
Perhaps you could put relative symlinks in task/? Something like this:
$ ls -l /proc/self/task dr-xr-xr-x 3 davidm users 0 Feb 26 11:37 13494 -> .. dr-xr-xr-x 3 davidm users 0 Feb 26 11:37 13495 -> ../../13495
perhaps?
--david - 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/
| |