Messages in this thread | | | Date | Tue, 18 Jan 2000 06:28:42 -0500 (EST) | From | Alexander Viro <> | Subject | Re: Why wrapping PIDs is evil [was 32bit] |
| |
On Tue, 18 Jan 2000, Khimenko Victor wrote:
> Interesting question: will `cd /proc/1234' work as `grab 1234' or not ? > I'm not know kernel internals enough to answer but to me it looks like > logical thing to do.
No, it will not. And should not, BTW. procfs inodes keep a pointer to task_struct and if the task exits the task_struct becomes recognizable as dead. It's excluded from all lists, but is kept from reuse until all such inodes will go away. Any attempt to access a procfs inode checks whether the process is still alive and fails if it isn't (i.e. we emulate the effect of revoke() by hands here). There is an exclusion between the part of exit(), part of exec() and parts of procfs methods, so that we are guaranteed that task_struct fields will not be yanked from under us. The only case when procfs does search for task_struct is when we are entering the /proc/<pid> - anything deeper uses the pointer from parent inode. And dentries of /proc/<pid> have ->revalidate() which invalidates them if the task is dead. Since we do not use icache anymore, inumbers are irrelevant. They are faked for stat(2) and readdir(2), but that's it. If you want to support larger range of PIDs procfs will not be a problem - just decide what you will tell stat() and friends (see fs/proc/base.c::fake_ino definition and comment immediately above).
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |