On Mon, 27 Mar 2000, 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
> to promise integrity -- then you can choose to run with no 'virtual swap' and
> guaranteed _minimum_ stack space sizes allocated at run time. With the
> current model, say, auditd could think it malloc'ed a 2Meg buffer -- thus
^^^^^^^^^
> it thinks it has it's space guaranteed. If we are in a OOM state, when auditd
> goes to access that buffer, it will SEGV -- can't map address to physical
> object, or a "OOM" killer routine runs and kills another process pseudo
> randomly. What I'm saying is we need to provide a model that doesn't
> overcommit. You, personally, or anyone else doesn't have to use that model.
> But such a model, if in the kernel would allow for operational assurance
> (allowing for failures to occur predictably).
If you use plain malloc(), you're not allowed to think you have any
space guaranteed. It's bad programming. If you need guaranteed "space"
(memory) use another kernel interface, such as mlock(). I'm not saying
the current interface is perfect. I'm just saying that overcommitting
is not the problem. You don't need to turn overcommiting off. You
need you use a better interface than malloc() to get "safe" memory.
For stack grow, maybe we need some way to tell the kernel:
"never page-out my stack, and reserve me this space...".
Applications should be able to bypass kernel management of their address
space. But this should be done on a per-app base.
[...]
> -l
>
> --
> Linda A Walsh | Trust Technology, Core Linux, SGI
> law@sgi.com | Voice: (650) 933-5338
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ Colombo@ESI.it
-
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:22 EST