Jim wants to the window manager to decide policy on out-of-memory conditions. Alan Cox says the kernel is doing the best it can and suggests auditing callers of malloc. Of course this is too much work, even for the small set of preinstalled OLPC software. Here an alternate idea: Suppose an out-of-memory daemon (omd) is forked by Xsesson.d/. The omd will preallocate a screen to ask the user which applications to kill to free up memory. (Or the policy could be entirely automated. I'm just using this as an example.) Wrap mmap, sbrk, and friends (via LD_PRELOAD or whatever). If sbrk finds that memory cannot be allocated then it writes the process ID and the # of bytes to a UNIX domain socket a la ucspi-unix[1] and waits for a policy decision. The cool thing about unix domain sockets on Linux is SO_PEERCRED which allows the kernel to tell you the UID of the process sending bytes through the socket. The omd is listening on this socket. If the uid doesn't match the uid on X and doesn't match a system uid (eg. root, bcron, log, qmail, etc) then it kills the offending process (so random people running stuff via ssh get killed first). Otherwise, it asks the user which process to kill. (Hrm, thinking out loud, part of omd probably needs to be running as root to make this work.) Anyway, with this solution we don't have to audit all the callers of malloc and we can still uphold the illusion that malloc never returns a NULL pointer if that's the decision of the holistic system policy. Comments? [1] http://untroubled.org/ucspi-unix/ -- Make April 15 just another day, visit http://fairtax.org
Attachment:
signature.asc
Description: Digital signature