Re: /proc visibility patch breaks GDB, etc.

From: David Mosberger
Date: Thu Feb 26 2004 - 14:43:28 EST


>>>>> On Wed, 25 Feb 2004 22:44:10 -0800, Andrew Morton <akpm@xxxxxxxx> said:

Andrew> Peter Chubb <peter@xxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/