> Well, conceivably the proc_put_inode code could check for dirty inodes
> and write them out directly. You'd need to check to be sure that the
> operations don't block though; at that point the inode is still hashed
> and could be reused.
Feasible, I suppose, and the write operations don't block, they are simple
little assignments. However I like the idea of solving this problem at the
VFS layer. Grep the sources for FS_NO_DCACHE, and it looks like this was
originally intended to be used for /proc.
I've discovered users of 2.1.x already _can_ hide their processes in a
slightly kludgy way, without my patch(!). If a fd pointing at a
/proc/<pid> directory is held open by a simple little background process,
then changes made to permissions/owner/etc. of the directory are retained
until the process exits!!! ugh! A system administrator might do a ps
and/or top under a non-privileged account, and hence miss some dodgy
process a user has cunningly "hidden". Not good.
> Also note that if some /proc entries weren't volatile and it actually
> made sense to keep the inodes around, we could define a persistant flag
> and not dispose of the inode. But for most cases it doesn't make sense
> to keep the old inode.
Perhaps we need a "volatile" flag? This would have to:
1) Immediately write out an inode on the last iput()
2) Force a new inode read _every_ iget() even if the inode is already in
memory?
One more question, with regards task pointers in fs/proc. Isn't it
possible we get a "struct task* p", but then the task has exited by the
time we dereference p?
Discuss?
Chris