The thorny case of kmalloc(0)

People running 2.6.22-rc kernels have likely noticed the occasional warning and traceback associated with zero-length allocations. It turns out that there is code in the kernel which asks kmalloc() to allocate a zero-sized object. Nobody really knew how often this happens until the warning went in as part of the SLUB allocator patch set; now that these cases are turning up, it seems that deciding what to do about them is harder than one might expect.

One possibility is to return NULL. On the face of it, this option would appear to make sense; the caller has requested that no memory be allocated, and kmalloc() has complied. The problem here is that a NULL pointer is already loaded with meaning. It says that the allocation has failed (which it didn't - there is always enough memory left to allocate another zero bytes) and is often used as an indicator that a particular structure or subsystem has not been initialized. More to the point, it seems that there is an occasional situation where a zero-length allocation is not entirely incorrect; consider the allocation of a structure which, as a result of the kernel's configuration options, has been optimized down to zero members. Coding around such cases is possible, but it is not clear that adding more twists and turns is worth the trouble when zero-length allocations can just be handled in kmalloc().

Another possibility is to return the smallest object that kmalloc() can manage - currently eight bytes. That is what kmalloc() has silently done for years. This solution appears to work, but it has the disadvantage of returning memory which can be written to. A zero-length allocation can arguably be correct, but it's hard to find anybody who would agree that storing data into a zero-length chunk of memory makes sense. Even highly compressed data cannot be expected to fit into that space in all situations. People who worry about finding bugs would much prefer that any attempt to actually write to memory allocated with kmalloc(0) caused the kernel to protest in a very noisy way.

That brings us to the third possibility: this patch from Christoph Lameter which causes kmalloc(0) to return a special ZERO_SIZE_PTR value. It is a non-NULL value which looks like a legitimate pointer, but which causes a fault on any attempt at dereferencing it. Any attempt to call kfree() with this special value will do the right thing, of course.

The final option seems like it should be the right course, allowing zero-length allocations without masking any subsequent incorrect behavior. Surprisingly, though, there is an objection here too: now every call to kmalloc(0) returns the same value. One might not think this would be a problem; subsequent zero-length allocations will all be zero bytes apart, just like the C standard says they should be. But some developers are worried that this behavior might confuse code which compares pointers to see if two objects are the same. There is also, apparently, an established coding pattern (in user space) which uses zero-length allocations as a way of generating a unique cookie value. If all zero-length allocations return the same pointer, these cookies lose their uniqueness.

That worry appears unlikely to carry the day, though; Linus says:

Add to this argument the fact that nobody seems to have discovered such a use of kmalloc() in the kernel yet, and the "unique cookie" argument runs out of steam. So some form of the ZERO_SIZE_PTR patch, with the warning removed, will probably find its way into the mainline - but probably not before 2.6.23.

---

(Log in to post comments)