Bug 218478 - GFS2 and ACL bug?
Summary: GFS2 and ACL bug?
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel
Version: 5.0
Hardware: i386
OS: Linux
Target Milestone: ---
: ---
Assignee: Steve Whitehouse
QA Contact: Dean Jansa
Depends On: 217129
TreeView+ depends on / blocked
Reported: 2006-12-05 18:08 UTC by Kiersten (Kerri) Anderson
Modified: 2007-11-30 22:07 UTC (History)
6 users (show)

Fixed In Version: RC
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-02-08 01:21:28 UTC
Target Upstream Version:

Attachments (Terms of Use)

Description Kiersten (Kerri) Anderson 2006-12-05 18:08:36 UTC
+++ This bug was initially created as a clone of Bug #217129 +++

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20061107
Fedora/ Firefox/

Description of problem:

Got this (see attachment to this bz) after mounting the gfs2 volume with acl
option.  Not really sure if it is new or related to my previous deadlock
problems, but thought I better submit it.  Maybe your latest patches are not in
this kernel and this is taken care of in your tree.  I was doing a couple finds.
 You will all see a sysreq dump included in case it helps.  Runnig devel
version, kernel kernel-devel-2.6.18-1.2849.fc6 and the latest updates to cman,
clvm, openais, etc.

FWIW, the find process is hung chewing through 100% CPU, I assume spinning on a

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Sorta reproducible (intermittant)

1.  Mount gfs2 volume with acl?
2.  use find to find a file

Actual Results:
Find a file (or not) with kernel errors

Expected Results:
Find a file (or not) without kernel errors///

Additional info:

-- Additional comment from gplindstrom@fiberpipe.net on 2006-11-24 02:09 EST --
Created an attachment (id=142039)
Kernel errors for gfs2 with ACL mount option

Kernel errors and sysreq dump of problem...

-- Additional comment from swhiteho@redhat.com on 2006-11-24 07:08 EST --
This is caused by some incorrect logic when checking the acl which hasn't
correctly worked out whether the inode is already locked or not and has tried to
lock it again. I'll try to come up with a patch shortly.

-- Additional comment from swhiteho@redhat.com on 2006-11-27 04:48 EST --
I've just pushed a patch to the -nmw git tree to fix this problem.

-- Additional comment from swhiteho@redhat.com on 2006-11-28 07:00 EST --
This is the URL of the fix:


I would have posted it yesterday, but it seems that kernel.org is very slow to
update these days. You can get a plain version from the "plain" link at the top
of the web page.

Comment 1 RHEL Program Management 2006-12-05 18:32:00 UTC
Quality Engineering Management has reviewed and declined this request.  You may
appeal this decision by reopening this request. 

Comment 2 Kiersten (Kerri) Anderson 2006-12-05 18:52:06 UTC
Hit the wrong button on the flag that caused the inadvertant close state.

Comment 3 Steve Whitehouse 2006-12-06 08:50:37 UTC
This is the URL for the patch for this bug, the commit id has changed since I
last posted the URL, but the patch is the same:


Comment 4 RHEL Program Management 2006-12-07 15:06:58 UTC
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update

Comment 5 Don Zickus 2006-12-14 01:06:57 UTC
in 2.6.18-1.2876.el5

Comment 6 RHEL Program Management 2007-02-08 01:21:28 UTC
A package has been built which should help the problem described in 
this bug report. This report is therefore being closed with a resolution 
of CURRENTRELEASE. You may reopen this bug report if the solution does 
not work for you.

Note You need to log in before you can comment on or make changes to this bug.