qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends


From: Avi Kivity
Subject: Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends
Date: Sat, 05 Dec 2009 19:23:59 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091203 Fedora/3.0-3.13.rc2.fc12 Thunderbird/3.0

On 12/05/2009 07:08 PM, malc wrote:

What's the impact of such usage?  What would improve for users if it
were eradicated?  For developers?

I believe the answer the first two questions is "nothing in particular",
and the answer to the last one is "hassle".  But I'd be happy to see
*specific* examples (code, not hand-waving) for where I'm wrong.

I'm opposed to "fixing" something without a real gain, not just because
it's work, but also because like any change it's going to introduce new
bugs.

I'm particularly critical of outlawing zero size for uses like
malloc(N*sizeof(T).  These are fairly common in our code.  Having to add
special treatment for N==0 is a trap for the unwary.  Which means we'll
never be done chasing this stuff.  Moreover, the special treatment
clutters the code, and requiring it without a clear benefit is silly.
Show me the benefit, and I'll happily reconsider.

For a specific example, let's look at the first example from my commit
message again: load_elf32(), load_elf64() in hw/elf_ops.h.  "Fix" for
its "broken" usage of qemu_mallocz(), shot from the hip, entirely
untested:
Excellent example, now consider this:

   read$ cat<<  eof | gcc -x c -
   #define _GNU_SOURCE
   #include<err.h>
   #include<unistd.h>
   #include<stdlib.h>
   #include<fcntl.h>

   int main (void)
   {
       int fd = open ("/dev/zero", 0);
       int ret;
       void *p = (void *) -1;

       if (fd == -1) err (1, "open");
       ret = read (fd, p, 0);
       if (ret != 0) err (1, "read");
       return 0;
   }
   eof
   read$ ./a.out
   a.out: read: Bad address


I don't see how this is relevant. Linux' read(2) may or may not be broken, but what does that have to do with breaking callers of qemu_malloc() for certain use cases?

--
Do not meddle in the internals of kernels, for they are subtle and quick to 
panic.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]