[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[olpc-software] graceful handling of out-of-memory conditions



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]