Subject: malloc(9) flag proposal - M_FAILOK
To: None <tech-kern@NetBSD.org>
From: Jaromir Dolecek <jaromir.dolecek@artisys.cz>
List: tech-kern
Date: 11/28/2001 13:25:47
--ELM1006950347-30319-0_
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII

Hi,
I'd like to add a flag which would say malloc(9) to fail
in M_WAITOK case, if the memory can't ever be allocated (we currently
panic() in this case).

In almost every case, it's a kernel code problem if it tries to allocate
huge chunks of memory. In majority of such cases, kernel code failed
to do proper bound checking and let invalid values slip through. Thus,
the panic in malloc(9) for M_WAITOK case when uvm_km_kmemalloc() fails
is reasonable and should stay.

However, in some cases, we don't want to use any arbitrary
limits, and can recover easily if the memory is not available.

One such case is e.g. the thing reported in kern/14721. The problem
there is that we generally want to allow as many open files per-process
as configured by administrator and physically possible by available
resources. However, if the code which expands the process file descriptor
array would hit the physical memory barrier, malloc() would just panic
ATM. Rather than panic, it would be preferable if the code would fail
gracefully in such case.

Opinions about this flag? Of course, it's use would be discouradged,
since it can hide real kernel bugs. However something like that would
be useful option to have in some special cases.

One thing to consider is whether we want a userland process
to cut considerable amount of KVA for it's structures.

Jaromir
-- 
Jaromir Dolecek <jaromir.dolecek@artisys.cz>
ARTISYS, s.r.o., Stursova 71, 61600 Brno, Czech Republic
phone: +420-5-41224836 / fax: +420-5-41224870 / http://www.artisys.cz

--ELM1006950347-30319-0_
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-2
Content-Disposition: attachment; filename=failok.diff
Content-Description: 

Index: sys/malloc.h
===================================================================
RCS file: /cvsroot/syssrc/sys/sys/malloc.h,v
retrieving revision 1.68
diff -u -p -r1.68 malloc.h
--- malloc.h	2001/11/17 03:50:27	1.68
+++ malloc.h	2001/11/28 11:34:52
@@ -48,10 +48,11 @@
 /*
  * flags to malloc
  */
-#define	M_WAITOK	0x0000
-#define	M_NOWAIT	0x0001
+#define	M_WAITOK	0x0000	/* can wait for resources */
+#define	M_NOWAIT	0x0001	/* do not wait for resources */
 #define	M_ZERO		0x0002	/* zero the allocation */
-
+#define	M_FAILOK	0x0004	/* can fail if requested memory can't never
+				 * be allocated */
 /*
  * Types of memory to be allocated
  */
Index: kern/kern_malloc.c
===================================================================
RCS file: /cvsroot/syssrc/sys/kern/kern_malloc.c,v
retrieving revision 1.66
diff -u -p -r1.66 kern_malloc.c
--- kern_malloc.c	2001/11/21 01:30:04	1.66
+++ kern_malloc.c	2001/11/28 11:35:00
@@ -279,7 +279,7 @@ malloc(size, type, flags)
 			 * are completely free and which are in buckets
 			 * with too many free elements.)
 			 */
-			if ((flags & M_NOWAIT) == 0)
+			if ((flags & (M_NOWAIT|M_FAILOK)) == 0)
 				panic("malloc: out of space in kmem_map");
 			splx(s);
 			return ((void *) NULL);

--ELM1006950347-30319-0_--