cluster-devel.redhat.com archive mirror
 help / color / mirror / Atom feed
* [Cluster-devel] cluster/gfs-kernel/src/gfs dir.c
@ 2006-09-26  5:32 wcheng
  0 siblings, 0 replies; 2+ messages in thread
From: wcheng @ 2006-09-26  5:32 UTC (permalink / raw)
  To: cluster-devel.redhat.com

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4
Changes by:	wcheng at sourceware.org	2006-09-26 05:32:17

Modified files:
	gfs-kernel/src/gfs: dir.c 

Log message:
	Bugzilla 205592:
	
	One problem we've found is that under heavy system load, memory could
	be in shortage that results in kmalloc() failure. In previous versions,
	upon kmalloc() failure, in certain code paths, sometime it was impossible
	to back out - so GFS either panic or hung. In newer versions of GFS, a fix
	was added to allow memory allocation falling back to vmalloc() if kmalloc()
	failed. Unfortuntely, the linux/vmalloc.h header was not added. Since the
	compiler has not been not able to get the correct vmalloc() prototype, it
	assumes the default that casts vmalloc() return code to "int" which is 4
	byes. This could cause panic with 64 machines (e.g. x86_64) that uses 8
	bytes addressing.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/dir.c.diff?cvsroot=cluster&only_with_tag=RHEL4&r1=1.8.2.4&r2=1.8.2.5

--- cluster/gfs-kernel/src/gfs/dir.c	2006/02/19 23:37:23	1.8.2.4
+++ cluster/gfs-kernel/src/gfs/dir.c	2006/09/26 05:32:17	1.8.2.5
@@ -64,6 +64,7 @@
 #include <asm/semaphore.h>
 #include <linux/completion.h>
 #include <linux/buffer_head.h>
+#include <linux/vmalloc.h>
 
 #include "gfs.h"
 #include "dio.h"



^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Cluster-devel] cluster/gfs-kernel/src/gfs dir.c
@ 2006-09-26 14:30 wcheng
  0 siblings, 0 replies; 2+ messages in thread
From: wcheng @ 2006-09-26 14:30 UTC (permalink / raw)
  To: cluster-devel.redhat.com

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL4U4
Changes by:	wcheng at sourceware.org	2006-09-26 14:30:56

Modified files:
	gfs-kernel/src/gfs: dir.c 

Log message:
	Bugzilla 205592:
	
	One problem we've found is that under heavy system load, memory could
	be in shortage that results in kmalloc() failure. In previous versions,
	upon kmalloc() failure, in certain code paths, sometime it was impossible
	to back out - so GFS either panic or hung. In newer versions of GFS, a fix
	was added to allow memory allocation falling back to vmalloc() if kmalloc()
	failed. Unfortuntely, the linux/vmalloc.h header was not added. Since the
	compiler has not been not able to get the correct vmalloc() prototype, it
	assumes the default that casts vmalloc() return code to "int" which is 4
	byes. This could cause panic with 64 machines (e.g. x86_64) that uses 8
	bytes addressing.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/dir.c.diff?cvsroot=cluster&only_with_tag=RHEL4U4&r1=1.8.2.4&r2=1.8.2.4.2.1

--- cluster/gfs-kernel/src/gfs/dir.c	2006/02/19 23:37:23	1.8.2.4
+++ cluster/gfs-kernel/src/gfs/dir.c	2006/09/26 14:30:55	1.8.2.4.2.1
@@ -64,6 +64,7 @@
 #include <asm/semaphore.h>
 #include <linux/completion.h>
 #include <linux/buffer_head.h>
+#include <linux/vmalloc.h>
 
 #include "gfs.h"
 #include "dio.h"



^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2006-09-26 14:30 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-09-26  5:32 [Cluster-devel] cluster/gfs-kernel/src/gfs dir.c wcheng
  -- strict thread matches above, loose matches on Subject: below --
2006-09-26 14:30 wcheng

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).