OpenVZ Forum


Home » Mailing lists » Devel » [RFC][PATCH] Do not set /proc inode->pid for non-pid-related inodes
Re: [RFC][PATCH] Do not set /proc inode->pid for non-pid-related inodes [message #17981 is a reply to message #17967] Thu, 22 March 2007 20:17 Go to previous messageGo to previous message
ebiederm is currently offline  ebiederm
Messages: 1354
Registered: February 2006
Senior Member
Dave Hansen <hansendc@us.ibm.com> writes:

> So, doesn't that problem go away (or at least move to be umount's duty)
> if we completely disconnect those inodes' lifetime from that of any
> process or pid namespace?

If the last process has exited the pid namespace I would like the
code to continue to behave as it currently does.

I would like readdir on /proc/ to not even try to show any pids when
there are no pids or pid related files in the pid namespace.

I would like /proc/self to completely disappear when the are not
any pids in the pid namespace.

I misspoke in when I said that /proc/<pid> was affected.  The function
is proc_pid_readdir and it is a subset of /proc/ so it gets a little 
confusing.

Eric

_______________________________________________
Containers mailing list
Containers@lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: Re: Re: Linux-VServer example results for sharing vs. separate mappings ...
Next Topic: [PATCH] Correct accept(2) recovery after sock_attach_fd()
Goto Forum:
  


Current Time: Fri Sep 05 22:13:21 GMT 2025

Total time taken to generate the page: 0.19287 seconds