"A month of sundays ago Linda Walsh wrote:"
> "Peter T. Breuer" wrote:
> > > 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.
A secure fork is one that returns 0 unless there are resources
available to back the process that will be forked, and marks the
spawned process as "secure" so that the kernel will know not to
kill IT if it deadlocks on memory contention.
> I'd be careful...we may be in agreement. I'd just prefer to see
Probably.
> 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
^ secure
> 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.
"Non-secure" processes can still be launched in the ordinary way (without
decrementing the reserved memory count). That's fine. If the kernel
goes OOM through overcommit it must kill one of those to recover leeway.
It knows that it need not kill any secured process because they have
done the accounting paperwork that proves that they have backing store
available.
> > 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...
Yes. Just so. I was pointing out the analogy. To complete it, your
problem is that processes have no limit on the amount of audit-events
they may produce. I suggest you limit them, and make the call to an
audit event return 0 when the audt trail cannot be made, and let the
program handle it. How do you feel about that!
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