"Peter T. Breuer" wrote:
> !! 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?
--- uh...well maybe...> "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. --- Well that's the sticky part -- what signal gets returned and is it trappable.
> > > 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 :-(. --- Um...you just redefined 'fork'. Fork==vfork on linux, currently there is no "secure" fork.
> 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! --- There ya go again...secure fork... Not that I'm against the concept at all, but it's not what we currently have. If you are going to have the kernel reserve memory for all of the COW pages, why not just have it reserve memory for pages needed to back space added by brk()?
> 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. --- I'd be careful...we may be in agreement. I'd just prefer to see the brk() issued handled in the kernel as well, for the kernel to go with the new motto: no memory allocations or process space increases w/o decrementing the reserved memory count. I'm also wanting to see 'virtual swap' added though for the many people who want overcommit. It should be per system selectable.
> > 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! --- Have to stop currently running processes from generating any more auditable events as well...
-l
-- Linda A Walsh | Trust Technology, Core Linux, SGI law@sgi.com | Voice: (650) 933-5338
- 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