Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 504086

Summary: GFS2: s_umount locking bug with gfs2meta filesystem type
Product: Red Hat Enterprise Linux 5 Reporter: Ben Marzinski <bmarzins>
Component: kernelAssignee: Ben Marzinski <bmarzins>
Status: CLOSED ERRATA QA Contact: Cluster QE <mspqa-list>
Severity: medium Docs Contact:
Priority: low    
Version: 5.4CC: adas, dzickus, nstraz, rpeterso, rwheeler, sghosh, swhiteho
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-09-02 08:54:24 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Possible fix
none
Another possible solution none

Description Ben Marzinski 2009-06-04 06:23:18 UTC 
Description of problem:
vfs_kern_mount() expects get_sb() to return the super_block with a write lock on the s_umount semaphore, gfs2_get_sb_meta() doesn't do this.

Version-Release number of selected component (if applicable):
kernel-2.6.18-150.el5 and many others

How reproducible:
Always

Steps to Reproduce:
1. mkfs.gfs2 -p lock_nolock -j1 /dev/sdb1
2. mount -t gfs2 /dev/sb1 /mnt/test
3. mount -t gfs2meta /mnt/test /mnt/meta
4. umount /mnt/meta
5. umount /mnt/test

  
Actual results:
umount hangs

Expected results:
umount completes.

Additional info:
Comment 1 Steve Whitehouse 2009-06-04 09:50:03 UTC 
Created attachment 346509 [details]
Possible fix

Ben, does this fix the issue for you? I gave it a quick test and it seems to work ok for simple test cases.
Comment 2 Steve Whitehouse 2009-06-04 10:07:33 UTC 
I think we should try and get an exception for this one, as it should be quite quick to verify the fix.
Comment 3 RHEL Program Management 2009-06-04 10:20:51 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
release.
Comment 4 Ben Marzinski 2009-06-04 21:41:42 UTC 
You fix works just fine.  However I wonder if it isn't overkill. until you do the path_put(), you should be protected from unmounts, right?  I don't see why we can't just do a down_write(&sb->s_umount) before the path_put()? It doesn't look like it's necessary to hold a s_umount write lock to modify s_active. Anyways we could always move the s_umount lock earlier if it is.

But I don't have any other problems with your way.  So if you prefer it that way, it's fine with me.
Comment 5 Ben Marzinski 2009-06-04 21:44:47 UTC 
Created attachment 346593 [details]
Another possible solution

Here's a one line patch that solves the problem the way I mentioned.  Like I said, if you prefer your patch, I'm fine with that.
Comment 6 Steve Whitehouse 2009-06-05 07:03:28 UTC 
There is another issue as well... the way we grab the ref to the sb was wrong according to the sb locking scheme. We really wanted to call grab_super() but this is not exported and it also requires taking another lock too.

After some though and consultation with Christoph he thinks that its better to use sget to solve this issue.
Comment 7 Steve Whitehouse 2009-06-05 14:14:14 UTC 
I've also posted a further patch relating to the first part of the developements outlined in my recent message to cluster-devel about gfs2-utils developments. That was after a further discussion with Christoph and we might want to incorporate that into any RHEL fix.... I'm not sure at the moment whether thats a good plan or not. What do you think?
Comment 8 Steve Whitehouse 2009-06-08 14:09:35 UTC 
Ben, can you post this for 5.4 now? Lets ignore that second patch - I think I'll not push that into upstream. Lets just focus on getting the known bug fixed for now.
Comment 9 Ben Marzinski 2009-06-08 23:52:27 UTC 
Posted.
Comment 10 Don Zickus 2009-06-11 15:37:44 UTC 
in kernel-2.6.18-153.el5
You can download this test kernel from http://people.redhat.com/dzickus/el5

Please do NOT transition this bugzilla state to VERIFIED until our QE team
has sent specific instructions indicating when to do so.  However feel free
to provide a comment indicating that this fix has been verified.
Comment 12 Nate Straz 2009-06-23 20:18:15 UTC 
Verified on kernel-2.6.18-154.el5
Comment 14 errata-xmlrpc 2009-09-02 08:54:24 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2009-1243.html