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]

Message-Id: <E1IGV6D-0000rM-00@dorka.pomaz.szeredi.hu>
Date:	Thu, 02 Aug 2007 09:27:57 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	torvalds@...ux-foundation.org
CC:	miklos@...redi.hu, linux-kernel@...r.kernel.org,
	linux-mm@...ck.org, akpm@...ux-foundation.org
Subject: Re: [RFC PATCH] type safe allocator

> >
> > I wonder why we don't have type safe object allocators a-la new() in
> > C++ or g_new() in glib?
> > 
> >   fooptr = k_new(struct foo, GFP_KERNEL);
> 
> I would object to this if only because of the horrible name.
> 
> C++ is not a good language to take ideas from, and "new()" was not it's 
> best feature to begin with. "k_new()" is just disgusting.
> 
> I'd call it something like "alloc_struct()" instead, which tells you 
> exactly what it's all about. Especially since we try to avoid typedefs in 
> the kernel, and as a result, it's basically almost always a struct thing.

Yeah, I'm not strongly attached to the "new" name, although I got used
to it in glib.  The glib API is broken in lots of ways, but g_new()
and friends are nice and useful.

> That said, I'm not at all sure it's worth it. Especially not with all the 
> various variations on a theme (zeroed, arrays, etc etc).

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, I suspect you would be better off just instrumenting 
> "sparse" instead, and matching up the size of the allocation with the type 
> it gets assigned to.

But that just can't be done, because kmalloc() doesn't tell us the
_intent_ of the allocation.  The allocation could be for an array, or
for a struct with a variable length string at the end, or it could be
multiple structs concatenated.  We have all sorts of weird stuff in
there that sparse would not be able to handle.

That's why alloc_struct() is better: it describes the intention exacly
"allocate the given object and return an appropriately typed pointer".

While kmalloc() just says "allocate a given sized memory chunk and
return an untyped pointer".

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