Messages in this thread | | | From | (Eric W. Biederman) | Date | Fri, 07 Nov 2008 08:58:34 -0800 | Subject | Re: [PATCH 2/7] proc: Implement support for automounts in task directories |
| |
Andrew Morton <akpm@linux-foundation.org> writes:
> I was thinking more along the lines of some repeated operation which > generates reclaimable storage, only nothing reclaims that storage > sufficiently promptly (the 500 second delay, perhaps). > > Like the problem we had with SLAB_DESTROY_BY_RCU and, umm, I think it > was route cache entries increasing like mad and not getting reaped.
Well what happens is I run reclaim that chain whenever a process exits or every 500s. The 500s is really the backup in case we don't have any processes exiting, which is a really strange workload.
Now maybe there is an extremely perverse case out there that can trigger some bad behavior. But I can't think of anything like that at the moment. It would require accessing a lot of /proc/<pid>/net directories and holding them open even after their files were gone, pinning a lot of mounts, and then use a lot of memory elsewhere. Where the problem would be that the code is not well tied in with memory reclaim.
A mount is not a big or expensive structure and it requires a fd somewhere to keep it alive past exit. Thinking back to my analysis on /proc a few years ago where I introduced struct pid to prevent lowmem exhaustion. I can't think of a case where it would be a problem or user triggerable. Basically you have to have a fd open for every proc inode that lives past process exit. And we have hard limits on the number of fds a process can open and limits on the number of processes we can have.
One of the things on my todo list to look at sometime is the issue that mounts can deny you the permission to delete a file or directory when the mount is in another mount namespace. It is a pretty nasty DOS from my opinion. Especially when the last process holding open the mount namespace oopses and there is no way to remove the mount. However that DOS is only available to root today so it doesn't feel like a huge danger. To fix that we would need to introduce some better mount reaping logic. Which I expect would remove the need for the proc_automounts. That is tricky subtle vfs logic and I don't plan to rush into it.
Eric
| |