lkml.org 
[lkml]   [2000]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:56    [W:0.032 / U:0.272 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site