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:48:43 -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:
> > 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.
> 
> Yeah, I was thinking about this too but decided against it (for now) as I am
> mostly concerned with removing the slab abuses from unionfs. Also, it is not
> immediately obvious we want to do this for all cases of krealloc so I'd prefer

Why not? Its a realloc call and these are the classic semantics of 
realloc. Otherwise realloc will always move the memory.

> to keep the API for a while and decide to optimize or not optimize later. Note
> that we would only get rid of one of the kfree callers, the other one doesn't
> want to do krealloc(), it never reuses the old values.

Check that both sizes fall into the same general cache. Do the following 
at the beginning of the function

struct kmem_cache *cachep = page_get_slab(virt_to_page(object));

if (new_size && cachep == kmem_find_general_cachep(new_size, 
cachep->gfpflags))
	/*
	 * Old and new object size us the same general slab so we do not 
	 * have to do anything
	 */
	return object;

-
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