linux-kernel - Re: [RFC PATCH] type safe allocator

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:	Thu, 2 Aug 2007 10:23:51 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Miklos Szeredi <miklos@...redi.hu>
cc:	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	akpm@...ux-foundation.org
Subject: Re: [RFC PATCH] type safe allocator



On Thu, 2 Aug 2007, Miklos Szeredi wrote:
> 
> The number of variations can be reduced to just zeroing/nonzeroing, by
> making the array length mandatory.  That's what glib does in g_new().

Quite frankly, you don't need the zeroing. That's what __GFP_ZERO does in 
the flags.

That said, I'm not at all sure that it's at all more readable to add some 
new abstraction layer and do

	struct random_struct *ptr;

	ptr = alloc_struct(random_struct, 1, GFP_KERNEL | __GFP_ZERO);

than just doing a

	ptr = kmalloc(sizeof(*ptr), GFP_KERNEL | __GFP_ZERO);

or

	ptr = kzalloc(sizeof(*ptr), GFP_KERNEL);

(and adding the zeroing variant of alloc_struct() just adds *more* 
confusing issues).

The fact is, type safety in this area is probably less important than the 
code just being readable. And have fifteen different interfaces to memory 
allocation just isn't ever going to readable - regardless of how good they 
are individually.

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