Messages in this thread | | | Date | Fri, 13 Mar 1998 21:32:46 +0000 (GMT) | From | Chris Evans <> | Subject | Re: procfs pre-2.1.90-2 Oops, bug in proc_delete_dentry or proc_delete_inode or something , similar |
| |
On Fri, 13 Mar 1998, Andrea Arcangeli wrote:
> >It's easier than that: > > > > rm -rf /proc > > > >does the trick just fine :-) > > With the difference that this can be run only by root. loading/unloading a > module can be done by kmod as well and an user can walk on /proc in the > meantime.
True, although the former still surely has to come under the category of "2.2 showstopper" since the system is in (little) pieces after that command.
Also, I'm _highly_ unimpressed with the line in /proc,
inode->i_nlink = 0
or similar. It has the effect that if an in-core inode is modified during its existance, it is possible for the changes to this inode to be dropped on the floor without ever hitting the write_inode call-back. I think this is conceptually _very_ poor even if the underlying filesystem is a pseudo-one.
Or to summarise, I think we should be able to state "if an inode is changed during its lifetime in-core, we guarantee the write_inode callback is called. This write_inode routine may of course silently discard the changes".
The reason I am whinging is that the i_nlink = 0 broken behaviour makes it very difficult to implement my "process privacy" patch, (chmod og-rwx /proc/<pid>, etc), and many people have been whining to me about getting it in the kernel :)
Finally note that by holding open a fd to a /proc/<pid> directory in 2.1.recent, I can arbitrarily hide my processes as is it. Bad, bad, bad (tm).
Chris
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |