Re: Avoiding OOM on overcommit...?

From: Peter T. Breuer (ptb@it.uc3m.es)
Date: Mon Mar 27 2000 - 07:08:17 EST


"A month of sundays ago David Whysong wrote:"
> On Mon, 27 Mar 2000, Peter T. Breuer wrote:
> >"A month of sundays ago David Whysong wrote:"
>
> >> the stack still dynamically grows, you have to make sure that you never
> >> use more than the preallocated backing store.
> >>
> >Yes. But there is nothing to make sure of. I propose that the process
> >cannot start unless it has the backing store for its rlimit available -
> >and that that store will be bound to it by the kernel for its and it
> >alones future use until death do it part.
>
> You want to reserve up to the hard rlimit? That can be a LOT of memory per
> process...

8MB. I don't have a problem with that. If you are running a secure system, you
can invest in the 2GB of swap space necessary to ensure that you have stack
for 256 processes of 8MB stack each. There's no magic. If you want to be
guarranteed that nobody steals your allocation, you have to have it available
to you alone.

> A malloc that touches all pages and returns zero on SIGSEGV is
> an elegant solution for the heap.
>
> Pre-allocating swap space up to the stack rlimit works, so long as the

Not just swap space, YOUR (stack) swap space. Not usable for any other
purpose except saving your stack pages and (notionally) getting new ones,
thhough it's really just a space to put new pages once they have to be
swapped out again for the next 4KB of ram that the kernel needs :-).

> kernel handles the case where the rlimit is increased. But this is a less

I don't believe you can increase it while the process is running, but I
may be wrong.

> elegant solution, because you waste some resources in the common case.
>
> I realize I'm splitting hairs here, and root is allowed to kill the
> system... but root can increase his hard rlimit.

Yes.

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:19 EST