"A month of sundays ago Linda Walsh wrote:"
> Horst von Brand wrote:
> > Not in itself, the problem is that if you don't ever want to overcommit
> > anything you must know exactly how much memory each activity could use, in
> > the very worst case.
> ---
> ??? But this is known. If a process mallocs 1 Meg of memory, you
> commit (reserve) one meg of physical memory/swap. If a process does an exec,
> you 'commit' (reserve) exactly all of the COW pages. In the case of stack,
!! Either you have performed an amazing volte face, or someone has been
whispering in your ear! How come you're now admitting that yes, it's
easy, and there's nothing to get all het up about?
> the user or sysadmin sets a minimum stack to run with -- lets say 128K or
> 1M -- whichever. That is the amount reserved. Then when I write reliable
> process, that limits it's stack usage to < the reserved value -- every call
> will return a reliable indicator "pass or fail". Never will I just be
> 'killed' because the system couldn't map memory it had already allocated
> to me.
This is precisely right. Moreover, you can choose which processes will
observe this policy and which won't, and kill the ones that won't when
you get deadlock in contention for overcommitted resources. The rest
are known to have backing, so there is no need to kill them, or to put
them to the test, for that matter.
> "Peter T. Breuer" wrote:
> >
> > "A month of sundays ago Linda Walsh wrote:"
> > > Well -- that's sorta the point -- Everything from 'atd' to 'vi'
> > > would need to be rewritten to 'touch' pages of alloc'ed memory. If you want
> >
> > Where do you get this from? Just change the malloc they use in libc.
> > This used to be commonly done to protect netscape from itself
> > (LD_PRELOAD = gnumalloc.o). This is and always has been trivial.
> ---
> That solves nothing. When you go to touch the memory, if you are
"You" already touched it, just before it was delivered to the program.
That's what the gnumalloc wrapper does. It traps (I hope!) the
signal and returns 0.
> at an OOM condition, your process faults because memory can't be mapped. You
> haven't returned an error that my program can deal with -- you just killed
See above. I don't understand how you can say this and simultaneously
put up the correct argument further above. Left/right brain schism?
> it. It also doesn't solve COW pages after a fork.
The fork can't happen unless there are resources to back it, if its a
secure fork. I commend you to vfork, too :-(.
> > Overcommitment is fine. If you don't want it, reserve your own backing
> > swap space for your stack. That's all. Then you can't be murdered by
> > the kernel because the kernel will always be able to page you out.
> ---
> ??? Without backing store reserved on stack, the kernel can always
> page you out. The problem is when trying to "touch your malloc space" or
No it can't. It might have swap and memory full up, leaving you with
nowhere to page too.
As to malloc space: that got touched before it was given to you, by the
gnumalloc wrapper.
> touch all of your COW pages after a fork (?!?) -- you don't get a nice
> reliable 'out of memory', or NULL pointer back from malloc, you just get
> killed because the kernel couldn't map memory for you at run time. Swapping
> has nothing to do with anything.
I really think there must be mental schisms happening within your neuronal
circuitry ... secure fork can't happen without the spare pages to back
it!
> If you have allowed overcommit, the results are less predictable for any
> app in the system. If it is _possible_to_disable_ overcommit, the mode
> of failure becomes easier to predict. Any given app can choose to deal
How can it be easier than the algorithm you got right first time in this
essay above? It can't happen to processes that use the secure policy,
because the kernel agrees not to kill them when it deadlocks on memory. And
secure processes can't start until the kernel has enough space to allow
it to follow this policy.
> with a NULL pointer from malloc, and any given app can choose to deal with
> a failure of a fork and in both cases react appropriately. Any given app
> could reserve (perhaps at 'ld' time) sufficient stack space for itself if
> it knows its own behavior. Then I can write well behaved apps that deal
> with insufficient resources in a sane manner -- not just randomly have my
> app or another 'die'.
This is all true and faintly vacuous ...
> ---
> The C2 specification says that when you can no longer record audit
> events, the system should prevent auditable events from occurring. Depending
> on what is being audited, Halting the system or deadlock would effective meet
> that requirement.
Mmm ... or just not start any more audit-event producing processes!
Peter
-
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/
This archive was generated by hypermail 2b29 : Fri Mar 31 2000 - 21:00:28 EST