All of lore.kernel.org
 help / color / mirror / Atom feed
From: Kurt Wall <kwall@kurtwerks.com>
To: linux-kernel@vger.kernel.org
Subject: Re: modutils-2.3.15 'insmod'
Date: Wed, 9 Jul 2003 12:08:23 -0400	[thread overview]
Message-ID: <20030709160823.GC267@kurtwerks.com> (raw)
In-Reply-To: <Pine.LNX.4.53.0307091119450.470@chaos>

Quoth Richard B. Johnson:
> 
> modutils-2.3.15, and probably later, has a bug that can prevent
> modules from being loaded from initrd, this results in not
> being able to mount a root file-system. The bug assumes that
> malloc() will return a valid pointer when given an allocation
> size of zero.

This isn't a bug. The standard allow returning a non-null pointer
for malloc(0).

> When there are no modules loaded, insmod scans for modules
> and allocates data using its xmalloc() based upon the number
> of modules found. If the number was 0, it attempts to allocate
> 0 bytes (0 times the size of a structure). If malloc() returns
> NULL (and it can, probably should), xmalloc() will write an
> "out of memory" diagnostic and call exit().
> 
> The most recent `man` pages that RH 9.0 distributes states that
> malloc() can return either NULL of a pointer that is valid for
> free(). This, of course, depends upon the 'C' runtime library's
> malloc() implementation.

Perhaps, but IIRC, the rationale in the GNU C library was that
existing programs assume malloc(0) != 0, which allows you to call
realloc on the pointer. Returning NULL only makes sense if the 
malloc() call fails.

> It is likely that malloc(0) returning a valid pointer is a bug
> that has prevented this problem from being observed. Such a
> bug in malloc() is probably necessary to keep legacy software

Not a bug. Bad design perhaps, but not a bug.

> running, but new software shouldn't use such atrocious side-effects.
> An allocation of zero needs to be discovered and fixed early
> in code design.

Kurt
-- 
If you sit down at a poker game and don't see a sucker, get up.  You're
the sucker.

  parent reply	other threads:[~2003-07-09 15:53 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-09 15:25 modutils-2.3.15 'insmod' Richard B. Johnson
2003-07-09 15:45 ` Andreas Schwab
2003-07-09 16:04   ` Bill Rugolsky Jr.
2003-07-09 22:44   ` H. Peter Anvin
2003-07-09 23:51     ` Richard B. Johnson
2003-07-09 16:08 ` Kurt Wall [this message]
2003-07-09 16:33   ` Andy Isaacson
2003-07-14 11:41 ` Keith Owens

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=20030709160823.GC267@kurtwerks.com \
    --to=kwall@kurtwerks.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.