From mboxrd@z Thu Jan 1 00:00:00 1970 From: wcheng@sourceware.org Date: 5 Jun 2007 18:21:23 -0000 Subject: [Cluster-devel] cluster/gfs-kernel/src/gfs ops_inode.c Message-ID: <20070605182123.31664.qmail@sourceware.org> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit CVSROOT: /cvs/cluster Module name: cluster Changes by: wcheng at 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 --- cluster/gfs-kernel/src/gfs/ops_inode.c 2007/06/05 18:15:51 1.17 +++ cluster/gfs-kernel/src/gfs/ops_inode.c 2007/06/05 18:21:22 1.18 @@ -151,9 +151,9 @@ gfs_inode_put(ip); if (!inode) - return -ENOMEM; - - error = gfs_security_init(dip, ip); + error = -ENOMEM; + else + error = gfs_security_init(dip, ip); gfs_glock_dq_uninit(&d_gh); gfs_glock_dq_uninit(&i_gh);