From: "Ihar 'Philips' Filipau" <filia@softhome.net>
To: root@chaos.analogic.com
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: 2.2/2.4/2.6 VMs: do malloc() ever return NULL?
Date: Wed, 26 Nov 2003 00:17:08 +0100 [thread overview]
Message-ID: <3FC3E2F4.4080809@softhome.net> (raw)
In-Reply-To: <Pine.LNX.4.53.0311251510310.6584@chaos>
Richard B. Johnson wrote:
>
> As documented, malloc() will never fail as long as there
> is still address space (not memory) available. This is
> the required nature of the over-commit strategy. This is
> necessary because many programs never even touch all the
> memory they allocate.
>
We are reading different mans? My man malloc(3) clearly states that
malloc() can return NULL. (*)
May I ask you one question? Did you were ever doing once graceful
failure of application under memory pressure? Looks like not.
I can guess why sendmail allocates memory it never touches - memory
pools. There are situations where you really cannot fail - and memory
allocation failures are really nasty. Do you wanna to lose your e-mails?
No? So then think twice, while implementing lazy allocators.
So from my tests I see that by default Linux is not safe. You allocate
memory - malloc() != NULL. Then later you try to write to this memory
and you get killed by oom_killer. What is the point of this? Your
reasoning doesn't sound to me.
Memory pools used by applications exactly to make grace error
handling under memory pressure - but it looks like this stuff under
Linux gets no testing at all. And default settings could make from
simple bug complete disaster.
> You can turn OFF over-commit by doing:
>
> echo "2" >proc/sys/vm/overcommit_memory
>
> However, you will probably find that many programs fail
> or seg-fault when normally they wouldn't. So, if you don't
> mind restarting sendmail occasionally, then turn off over-commit.
>
I shall try overcommit_memory == 2 tomorrow and say what I see.
P.S. For example application I have ported right now to kernel space has
a limitiation - it must never ever allocate memory: memory consumption
is known, protocol just have no situation like ENOMEM - it _must_ fail
to initialize on start-up. No - not to being killed by oom_killer in
middle of processing. think carrier grade and/or just good programming
technics.
(*) Great optimization opportunities: remove from all programmes checks
of the return value if malloc(). As by your words - why not?
--
Ihar 'Philips' Filipau / with best regards from Saarbruecken.
-- _ _ _
Because the kernel depends on it existing. "init" |_|*|_|
literally _is_ special from a kernel standpoint, |_|_|*|
because its' the "reaper of zombies" (and, may I add, |*|*|*|
that would be a great name for a rock band).
-- Linus Torvalds
next prev parent reply other threads:[~2003-11-25 23:17 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-25 13:27 2.2/2.4/2.6 VMs: do malloc() ever return NULL? Ihar 'Philips' Filipau
2003-11-25 14:00 ` Arjan van de Ven
2003-11-25 16:58 ` Rik van Riel
2003-11-25 19:03 ` Ihar 'Philips' Filipau
2003-11-25 19:24 ` Rik van Riel
2003-11-25 19:28 ` Chris Wright
2003-11-25 20:17 ` Richard B. Johnson
2003-11-25 23:17 ` Ihar 'Philips' Filipau [this message]
2003-11-25 23:40 ` Oliver
2003-11-26 13:06 ` Richard B. Johnson
2003-11-26 13:20 ` Ihar 'Philips' Filipau
2003-11-26 13:27 ` William Lee Irwin III
2003-11-26 14:33 ` Ihar 'Philips' Filipau
2003-11-26 14:36 ` William Lee Irwin III
2003-11-26 13:49 ` Richard B. Johnson
2003-11-26 14:39 ` Ihar 'Philips' Filipau
2003-11-26 7:31 ` Tim Connors
2003-11-26 9:58 ` William Lee Irwin III
[not found] <VLAm.2g1.9@gated-at.bofh.it>
[not found] ` <VM3n.3jY.9@gated-at.bofh.it>
2003-11-25 15:23 ` Ihar 'Philips' Filipau
[not found] <VQJL.62Q.11@gated-at.bofh.it>
[not found] ` <VR3c.6Ns.21@gated-at.bofh.it>
2003-11-26 10:30 ` Ihar 'Philips' Filipau
2003-11-26 10:39 ` William Lee Irwin III
2003-11-26 12:14 ` Ihar 'Philips' Filipau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3FC3E2F4.4080809@softhome.net \
--to=filia@softhome.net \
--cc=linux-kernel@vger.kernel.org \
--cc=root@chaos.analogic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.