>On 08-Oct-98 Stefan Monnier wrote:
>>>>>>> "Helge" == Helge Hafting <helge.hafting@daldata.no> writes:
>>> clean up and leave its files in a sane state. Such cleanup code must of
>>> course be written without further allocations.
>>
>> Including *stack* allocation, of course.
>Or allocating pages to fault in a hitherto unused piece of code...
Yes - this is difficult. Calling a cleanup function
will push a return address, which will be a problem *if* the
stack is on the edge of the last page *and* there isn't a single page
available. Not all that likely. The stack pointer will usually be
somewhere inside a page, and the failed malloc() may be for much more than
a single page, so a few pages
might be available. This is not perfect, but works most
of the time. Ugly setjmp constructs may be used for
avoiding stack usage completely and possibly free up some
stack pages as well.
Avoiding the fault to a unused page is impossible unless it is a one-page
program. But this problem may be solved by letting malloc() fail before
we are *completely* out of memory. I.e. malloc() and fork() fail when
overcommitment goes above some treshold, so
paging will still work. Setting the treshold will then be an
administrator option, depending on how much reliability is needed.
A 100% failsafe program or os will usually be impractical, but something
that works nice and reliable most of the time may not be so hard.
I sometimes writes functions with series of allocations, and if one of
them fails everything is freed before returning with an error status.
This tends to work well for me, and lets the main program keep running.
Not all programs need OOM-protection, but it is nice for some cases.
Helge
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/