"A month of sundays ago David Whysong wrote:"
>
> This whole issue can be easily solved by adding an int to task_struct, a
Well, that's just due to the fact that you have to flag secure
processes in some way.
> The modified OOM killer checks each task_struct for the new field, and
> modifies it's behavior accordingly. When you start a `secure' process,
> make sure this int is properly set so the kernel won't kill your process
> unless init is the only remaining alternative.
Given a whole int instead of a bit, one can be more subtle than that!
> In this case, the only time a `secure' process will ever fail is if your
> machine is HOPELESSLY overloaded AND no non-secure processes are running.
I don't think you got this. No, the secure process cannot fail. The
accounting guarantees that in this situation the kernel will have
the room available that it needs for OOM free running.
> The "safe gnumalloc" solution is okay, but wastes memory. The same is true
That is true.
> of stack preallocation. I think it's better to keep overcommit and have
That is not true, but you have misplaced a word: instead of
"preallocation", you meant "accounting".
> some user-level control over what we kill.
Overcommit has never been banished.
> This is simple, reliable, and efficient. Policy is completely in
> user-space. It is also secure -- the 'secure' task(s) never fail unless
> the alternative is to hang the machine. And if you wish, you can easily
> deadlock or hang the machine instead of killing secure tasks; if the
> int=MAXINT then never kill the task no matter what. Make your audit
> daemon, init, and whatever else unkillable.
>
> You can also implement memory quotas completely independent of this
This is also true. It's an alternative to the gnumalloc idea. It would
work like sstack accounting.
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