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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Thu, 2 Aug 2007 12:16:23 -0700 (PDT)
From:	Christoph Lameter <clameter@....com>
To:	Miklos Szeredi <miklos@...redi.hu>
cc:	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org
Subject: Re: [RFC PATCH] type safe allocator

On Thu, 2 Aug 2007, Miklos Szeredi wrote:

> > If you define a new flag like GFP_ZERO_ATOMIC and GFP_ZERO_KERNEL you 
> > could do
> > 
> > 	kalloc(struct, GFP_ZERO_KERNEL)
> > 
> > instead of adding new variants?
> 
> I don't really like this, introducing new gfp flags just makes
> grepping harder.

The __GFP_ZERO flag has been around for a long time. GFP_ZERO_ATOMIC and 
GFP_ZERO_KERNEL or so could just be a shorthand notation.

Maybe

#define GFP_ZATOMIC (GFP_ATOMIC | __GFP_ZERO)
#define GFP_ZKERNEL (GFP_KERNEL | __GFP_ZERO)

?

> I do think that at least having a zeroing and a non-zeroing variant
> makes sense.

They require a duplication of the API and have led to inconsistencies 
because the complete API was not available with zeroing capabilities 
(there is still no kzalloc_node f.e.). 
Using a gfp flag allows all allocation functions to optionally zero data 
without having to define multiple functions.

The definition of new variants is a bit complicated since the allocator 
functions contain lots of smarts to do inline constant folding. This is 
necessary to determine the correct slab at compile time. I'd rather have 
as few of those as possible.
-
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