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] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1IGYuK-0001Jj-00@dorka.pomaz.szeredi.hu>
Date:	Thu, 02 Aug 2007 13:31:56 +0200
From:	Miklos Szeredi <miklos@...redi.hu>
To:	akpm@...ux-foundation.org
CC:	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	torvalds@...ux-foundation.org
Subject: [PATCH] type safe allocator

From: Miklos Szeredi <mszeredi@...e.cz>

The linux kernel doesn't have a type safe object allocator a-la new()
in C++ or g_new() in glib.

Introduce two helpers for this purpose:

   alloc_struct(type, gfp_flags);

   zalloc_struct(type, gfp_flags);

These macros take a type name (usually a 'struct foo') as first
argument and the usual gfp-flags as second argument.  They return a
pointer cast to 'type *'.

The traditional forms of allocating a structure are:

  fooptr = kmalloc(sizeof(*fooptr), ...);

  fooptr = kmalloc(sizeof(struct foo), ...);

The new form is preferred over these, because of it's type safety and
more descriptive nature.

Signed-off-by: Miklos Szeredi <mszeredi@...e.cz>
---

Index: linux-2.6.22/include/linux/slab.h
===================================================================
--- linux-2.6.22.orig/include/linux/slab.h	2007-08-01 16:47:41.000000000 +0200
+++ linux-2.6.22/include/linux/slab.h	2007-08-02 12:55:20.000000000 +0200
@@ -110,6 +110,20 @@ static inline void *kcalloc(size_t n, si
 	return __kzalloc(n * size, flags);
 }
 
+/**
+ * alloc_struct - allocate given type object
+ * @type: the type of the object to allocate
+ * @flags: the type of memory to allocate.
+ */
+#define alloc_struct(type, flags) ((type *) kmalloc(sizeof(type), flags))
+
+/**
+ * zalloc_struct - allocate given type object, zero out the contents
+ * @type: the type of the object to allocate
+ * @flags: the type of memory to allocate.
+ */
+#define zalloc_struct(type, flags) ((type *) kzalloc(sizeof(type), flags))
+
 /*
  * Allocator specific definitions. These are mainly used to establish optimized
  * ways to convert kmalloc() calls to kmem_cache_alloc() invocations by selecting
Index: linux-2.6.22/Documentation/CodingStyle
===================================================================
--- linux-2.6.22.orig/Documentation/CodingStyle	2007-07-09 01:32:17.000000000 +0200
+++ linux-2.6.22/Documentation/CodingStyle	2007-08-02 13:03:48.000000000 +0200
@@ -631,21 +631,20 @@ Printing numbers in parentheses (%d) add
 		Chapter 14: Allocating memory
 
 The kernel provides the following general purpose memory allocators:
-kmalloc(), kzalloc(), kcalloc(), and vmalloc().  Please refer to the API
+kmalloc(), kzalloc(), kcalloc(), and vmalloc(), and the following
+helpers: alloc_struct() and zalloc_struct().  Please refer to the API
 documentation for further information about them.
 
-The preferred form for passing a size of a struct is the following:
+The preferred form for allocating a structure is the following:
 
-	p = kmalloc(sizeof(*p), ...);
+	p = alloc_struct(struct name, ...);
 
-The alternative form where struct name is spelled out hurts readability and
-introduces an opportunity for a bug when the pointer variable type is changed
-but the corresponding sizeof that is passed to a memory allocator is not.
-
-Casting the return value which is a void pointer is redundant. The conversion
-from void pointer to any other pointer type is guaranteed by the C programming
-language.
+The alternatives are less readable or introduce an opportunity for a bug
+when the pointer variable type is changed but the corresponding sizeof that
+is passed to a memory allocator is not.
 
+The return value of alloc_struct() and zalloc_struct() have the right type,
+so the compiler will warn if it is assigned to a pointer of different type.
 
 		Chapter 15: The inline disease
 
-
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