From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31658 invoked by alias); 5 Jun 2007 18:21:23 -0000 Received: (qmail 31644 invoked by uid 9572); 5 Jun 2007 18:21:23 -0000 Date: Tue, 05 Jun 2007 18:21:00 -0000 Message-ID: <20070605182123.31643.qmail@sourceware.org> From: wcheng@sourceware.org To: cluster-cvs@sources.redhat.com Subject: cluster/gfs-kernel/src/gfs ops_inode.c Mailing-List: contact cluster-cvs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: cluster-cvs-owner@sourceware.org X-SW-Source: 2007-q2/txt/msg00257.txt.bz2 CVSROOT: /cvs/cluster Module name: cluster Changes by: wcheng@sourceware.org 2007-06-05 18:21:23 Modified files: gfs-kernel/src/gfs: ops_inode.c Log message: Bugzilla 242759: Bump into this problem while debugging bug #236565 (GFS SPECsfs panic). Apparently a minor oversight while adding new function into GFS for RHEL5. GFS versions <= RHEL4 is immuned from this issue. Upon memory pressure, VM starts to release inode cache entries that would fail gfs iget. GFS1 flags this error as "ENOMEM" but returns from gfs_create call without releasing the glock. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_inode.c.diff?cvsroot=cluster&r1=1.17&r2=1.18