lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070604182208.GB10438@cvg>
Date:	Mon, 4 Jun 2007 22:22:08 +0400
From:	Cyrill Gorcunov <gorcunov@...il.com>
To:	Pekka Enberg <penberg@...helsinki.fi>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Christoph Lameter <clameter@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, jeremy@...p.org
Subject: Re: SLUB: Return ZERO_SIZE_PTR for kmalloc(0)

[Pekka Enberg - Mon, Jun 04, 2007 at 07:37:01PM +0300]
| On 6/4/07, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
| >Well, the red-zones won't catch readers, and more importantly, even for
| >writers they are *really* inconvenient, because it will just tell you
| >something bad happened, it won't tell you *where* it happened.
| 
| True.
| 
| On 6/4/07, Linus Torvalds <torvalds@...ux-foundation.org> wrote:
| >Since comparing the addresses of two zero-sized allocations is insane and
| >not done _anyway_, it's just much better to return an invalid address.
| 
| Then we might as well return your regular NULL pointer for zero-length
| allocations as you can't do anything sane with ZERO_SIZE_PTR either.

Hi Pekka,

you know, I'm absolutely agree with you. Hey, kernel hackers don't blame
me ;). But lets just take an example from a real life: I'm asking for
someone to give me 50 cents he would probably give me this. But if I'm
asking someone to give me 0 cents - he''ll give me nothing!!! Nobody
giving me a spec. papper on which "zero cents" is written. :)
So the code

	p = kmalloc(0);
	if (!p) {
		return -ENOMEM;
	}

is absolutely right - we physically have _no_ zero-sized memory. And as result
we have no reason to keep spec. slab to track zero-sized allocs.

Please, don't get me wrong, I'm not a kernel specialist...
And sorry for meddling into coversation.

		Cyrill

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ