Re: 2.2/2.4/2.6 VMs: do malloc() ever return NULL?

From: Tim Connors (tconnors+linuxkernel1069831506_at_astro.swin.edu.au)
Date: 11/26/03

  • Next message: Suparna Bhattacharya: "Re: [PATCH 2.6.0-test9-mm5] aio-dio-fallback-bio_count-race.patch"
    To: linux-kernel@vger.kernel.org
    Date:	Wed, 26 Nov 2003 18:31:37 +1100
    
    

    "Richard B. Johnson" <root@chaos.analogic.com> said on Tue, 25 Nov 2003 15:17:28 -0500 (EST):
    > On Tue, 25 Nov 2003, Ihar 'Philips' Filipau 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.
    >
    > 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 consider this a bug. If they don't use the memory, don't alloc
    it. It's not the responsibility of the kernel to determine whether the
    programmer was sane. If the programmer was sane, then he may well have
    been trying to keep some memory availble for emergency use, and
    wouldn't want his program dying from an untrapable kill signal.

    Or he was just lazy, and if he's lazy enough to allocate too much
    memory, he'll also be lazy enough to "forget" to check for malloc()s
    return value, and hence his program will crash when derefencing
    NULL. Bug reports will be filed against his application, like it was
    meant to, because it was his fault. Not the kernel's.

    Hence 2 should be the default.

    0 should be left for those poor fools who run closed source software,
    and can't get their vendor to fix their bugs, so need to use some
    kernel kludges (ie, overcommit) to get around it.

    -- 
    TimC -- http://astronomy.swin.edu.au/staff/tconnors/
    "Consider a spherical bear, in simple harmonic motion..."
                    -- Professor in the UCB physics department
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at  http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at  http://www.tux.org/lkml/
    

  • Next message: Suparna Bhattacharya: "Re: [PATCH 2.6.0-test9-mm5] aio-dio-fallback-bio_count-race.patch"

    Relevant Pages

    • Re: Errors locking offscreen surface if application heap is large
      ... whats the memory map for the machines, ... > few different memory configs, and a few different graphics card configs, and ... >> In these conditions I see calls to Lock a plain offscrreen surface fail ...
      (microsoft.public.win32.programmer.directx.graphics)
    • Re: Possible Bug in mincore or mmap
      ... kernels fail one instance of the mincore01 tests: ... to fail as it is asking for memory information 5 times what should be ... It shouldn't be a security problem if mincore doesn't actually ... it appears the mmap function is allowing read access ...
      (Linux-Kernel)
    • Re: 2.2/2.4/2.6 VMs: do malloc() ever return NULL?
      ... mallocwill never fail as long as there ... > malloc() can return NULL. ... It returns NULL if it fails to allocate memory. ...
      (Linux-Kernel)
    • Re: [OT]Re: malloc
      ... Since malloc fails gracefully, ... Memory allocation on FreeBSD can STILL fail: ... In addition to and above, setting option V will ...
      (comp.lang.c)
    • Re: [OT]Re: malloc
      ... Since malloc fails gracefully, ... Not *all* typical desktops perform the same; ISTR that FreeBSD ... Memory allocation on FreeBSD can STILL fail: ...
      (comp.lang.c)