From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <cluster-cvs-return-6596-listarch-cluster-cvs=sources.redhat.com@sourceware.org>
Received: (qmail 14944 invoked by alias); 5 Jun 2007 17:46:39 -0000
Received: (qmail 14914 invoked by uid 9572); 5 Jun 2007 17:46:38 -0000
Date: Tue, 05 Jun 2007 17:46:00 -0000
Message-ID: <20070605174638.14913.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: <cluster-cvs.sourceware.org>
List-Subscribe: <mailto:cluster-cvs-subscribe@sourceware.org>
List-Post: <mailto:cluster-cvs@sourceware.org>
List-Help: <mailto:cluster-cvs-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: cluster-cvs-owner@sourceware.org
X-SW-Source: 2007-q2/txt/msg00254.txt.bz2

CVSROOT:	/cvs/cluster
Module name:	cluster
Branch: 	RHEL5
Changes by:	wcheng@sourceware.org	2007-06-05 17:46:38

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

Log message:
	Bugzilla 242759
	
	Upon memory pressure, vm could start to release inode cache entries.
	Any process trying to get an inode during this time period will fail.
	GFS flags the error as "ENOMEM" but leaves gfs_create() call without
	unlocking the associated directory and file glocks. This patch fixes
	this minor coding oversight.

Patches:
http://sourceware.org/cgi-bin/cvsweb.cgi/cluster/gfs-kernel/src/gfs/ops_inode.c.diff?cvsroot=cluster&only_with_tag=RHEL5&r1=1.15.2.1&r2=1.15.2.2