3 ms·
Would it be hard to fix this specifically in the kernel? I don't know the details of the implementation, but I suppose those regions of memory holding the requi
by ambrop7 12y ago
Would it be hard to fix this specifically in the kernel? I don't know the details of the implementation, but I suppose those regions of memory holding the required information for /proc to work could be made always accessible, even if a process has hit its memory limit.
- amluto 12y agoAt the very least the kernel should sleep interruptably.
- Someone1234 12y agoThen it isn't a limit at all, it is a suggestion. If something running within a cgroup can exceed what the cgroup allows then the cgroup is completely worthless as a concept. Plus you have to assume some cgroups might be TRYING to DOS the machine its running on (e.g. shared hosting). If you give them a way to bypass the protections of cgroup and use up additional memory then they WILL take out the machine.
- ambrop7 12y agoThat the process is being memory limited shouldn't make it impossible for another process to read its cmdline. The cmdline data of the process should already be in memory. EDIT: I suspect that this problem is a consequence of a silly design that argv in the process holds the cmdline. Since apparently you can change the process name by changing argv, see: http://www.uofr.net/~greg/processname.html http://www.uofr.net/~greg/processname.html This seems to allow any process to mess with what the kernel sees as the cmdline. I hope there's not a "more" serious security issue hiding. This is more of a suspicion than fact, I'm planning to look into the kernel code to get more info on that.
- npsimons 12y agoThis is fixed in the kernel; the fix is called "oom-killer". You turn it off and write your own, you take your chances.