[lkml]   [1997]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patches in this message
SubjectSerious bugs in kernel - related to misuse of GFP_ATOMIC

All linux users are worried of 'Could not get a free page'. I keep
telling them that it is normal and that kernel should handle that.

PLEASE, David or Linus, tell me I'm right:

Anyone, who kmalloc's with priority of GFP_ATOMIC must be ready to get
NULL, as it is perfectly legal (it should not happen too often, but it
can happen, sometimes; if GFP_ATOMIC allocation fails, it should lead
only to some slowdown.)

So I created a small patch: It artifically makes about 1/2 of atomic
allocations to fail. (Cruel, is not it?)

Well, and I seen this (random) problems: [Note, that all of them may
happen anytime to anyone]

* System failed to start init. No message given.
* /proc fails to mount. Silently.
* Obvious bug in arp_alloc causes Oops. (patch below)
* Can not lock lock file /etc/mtab (or something similar)
* rpc.nfsd locked up
* syslogd locked up

I also added code I used for my test. Maybe 1/2 of failed allocations
is too much for normal use, but it is _really_ good for test, and IMO
this should be included in development kernel so writers of drivers
could test them under weird circumstances etc.


Testing patch:

Index: linux/arch/i386/
RCS file: /home/pavel/cvsroot/linux/arch/i386/,v
retrieving revision 1.10
diff -u -r1.10
--- 1997/09/07 16:20:43 1.10
+++ 1997/09/17 21:57:55
@@ -107,6 +107,7 @@
bool 'SMP Profiling' CONFIG_SMP_PROF
bool 'Magic SysRq key' CONFIG_MAGIC_SYSRQ
+bool 'Unreliable kmalloc' CONFIG_UNRELIABLE_MALLOC

Index: linux/mm/slab.c
RCS file: /home/pavel/cvsroot/linux/mm/slab.c,v
retrieving revision 1.5
diff -u -r1.5 slab.c
--- slab.c 1997/08/16 17:04:13 1.5
+++ slab.c 1997/09/17 21:58:31
@@ -1358,7 +1358,12 @@
kmem_bufctl_t *bufp;
void *objp;
unsigned long save_flags;
+#define RANDOM (! (jiffies & 1))
+ if ((flags & SLAB_LEVEL_MASK) == SLAB_ATOMIC)
+ if (RANDOM)
+ return NULL;
/* Sanity check. */
if (!cachep)
goto nul_ptr;
Small patch for obvious bug in arp.c:

Index: linux/net/ipv4/arp.c
RCS file: /home/pavel/cvsroot/linux/net/ipv4/arp.c,v
retrieving revision 1.2
diff -u -r1.2 arp.c
--- arp.c 1997/06/09 15:01:11 1.2
+++ arp.c 1997/09/17 21:58:32
@@ -797,10 +797,11 @@

entry = (struct arp_table *)neigh_alloc(sizeof(struct arp_table),
- atomic_set(&entry->u.neigh.refcnt, 1);

if (entry != NULL)
+ atomic_set(&entry->u.neigh.refcnt, 1);
if (how)

 \ /
  Last update: 2005-03-22 13:40    [W:0.025 / U:0.776 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site