linux-kernel - Re: [PATCH 1/3] slab: introduce krealloc

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]

Date:	Wed, 21 Feb 2007 10:27:06 -0800 (PST)
From:	Christoph Lameter <clameter@....com>
To:	Pekka Enberg <penberg@...helsinki.fi>
cc:	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	jsipek@....cs.sunysb.edu, unionfs@...esystems.org, bunk@...sta.de,
	hooanon05@...oo.co.jp
Subject: Re: [PATCH 1/3] slab: introduce krealloc

On Wed, 21 Feb 2007, Pekka Enberg wrote:

> Christoph Lameter wrote:
> > Well could you check ksize for the old object first and if ksize <= new size
> > then just skip the copy? I think this may allow you to get rid of the ksize
> > callers.
> 
> And not reallocate at all, right? I thought about that but then you wouldn't
> be able to use realloc() to make the buffer smaller.

I think there are two ways to address that:

1. Just do not allow shrinking via realloc. Probably no big loss and best 
performance.

2. Check if the size specified is larger than the next smallest general 
cache and only copy if we would really would allocate from a different 
cache.

-
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/