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: <51189954-4301-4C83-91F2-26B376D0DDD7@mac.com>
Date:	Sat, 25 Aug 2007 21:52:51 -0400
From:	Kyle Moffett <mrmacman_g4@....com>
To:	Jesper Juhl <jesper.juhl@...il.com>
Cc:	"Robert P. J. Day" <rpjday@...dspring.com>,
	Denys Vlasenko <vda.linux@...glemail.com>,
	linux-mtd@...ts.infradead.org,
	David Woodhouse <dwmw2@...radead.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 09/30] mtd: Don't cast kmalloc() return value in drivers/mtd/maps/pmcmsp-flash.c

On Aug 25, 2007, at 20:36:32, Jesper Juhl wrote:
> On 26/08/07, Robert P. J. Day <rpjday@...dspring.com> wrote:
>> technically, nothing.  but if you're not going to use kcalloc()  
>> when you're explicitly allocating an array of identical objects  
>> (that you want zero-filled, as a bonus), then what's the point of  
>> ever having defined a kcalloc() routine in the first place?
>>
> I wonder a bit about that myself...
>
> I have found some other issues in that function that I want to fix,  
> so I'll be respinning the patch as a patch series instead - and why  
> not; I'll just go with kcalloc() and see what the maintainers have  
> to say, it's not like I personally care much one way or the other.

I think the original reasoning behind kcalloc() was that it did some  
extra input checking, so that if the product of the two numbers  
overflowed, it would fail with NULL instead of allocating  
insufficient space.  In the kernel it doesn't matter in practice  
since you MUST have additional checking on the size of allocated  
memory anyways, not even considering the fact that >PAGE_SIZE  
allocations are probably going to fail with decent frequency regardless.

Cheers,
Kyle Moffett


-
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