From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5344 invoked by alias); 26 Sep 2006 05:32:18 -0000 Received: (qmail 5320 invoked by uid 9572); 26 Sep 2006 05:32:17 -0000 Date: Tue, 26 Sep 2006 05:32:00 -0000 Message-ID: <20060926053217.5319.qmail@sourceware.org> From: wcheng@sourceware.org To: cluster-cvs@sources.redhat.com Subject: cluster/gfs-kernel/src/gfs dir.c Mailing-List: contact cluster-cvs-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: cluster-cvs-owner@sourceware.org X-SW-Source: 2006-q3/txt/msg00704.txt.bz2 List-Id: CVSROOT: /cvs/cluster Module name: cluster Branch: RHEL4 Changes by: wcheng@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