RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 766554 - ecryptfs keeps directory busy even after umount
Summary: ecryptfs keeps directory busy even after umount
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: kernel
Version: 6.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Brian Foster
QA Contact: Radek Pazdera
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-12 10:53 UTC by Michal Hlavinka
Modified: 2013-10-23 23:32 UTC (History)
5 users (show)

Fixed In Version: kernel-2.6.32-231.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-06-20 08:09:52 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 892497 0 None None None Never
Red Hat Product Errata RHSA-2012:0862 0 normal SHIPPED_LIVE Moderate: Red Hat Enterprise Linux 6 kernel security, bug fix and enhancement update 2012-06-20 12:55:00 UTC

Description Michal Hlavinka 2011-12-12 10:53:29 UTC 
Description of problem:
It's not possible to umount directory, where ecryptfs was mounted.

Version-Release number of selected component (if applicable):
kernel-2.6.32-220.el6.x86_64

How reproducible:
always

Steps to Reproduce:
mount something at /mnt/test, either some partition or disk image:
mkdir /mnt/test
dd if=/dev/zero of=disk.img bs=1M count=100
mkfs.ext3  disk.img
mount disk.img /mnt/ -oloop

cd /mnt/test
mkdir 1 2
mount -t ecryptfs 1 2
umount 2
cd /
umount /mnt/test

Actual results:
umount: /mnt/test: device is busy

output of both:
lsof | grep mnt/test  and  fuser -cu /mnt/test
is empty


Expected results:
/mnt/test umounted

Additional info:
works in Fedora
Comment 2 Brian Foster 2012-02-06 17:19:56 UTC 
I spent a little time looking at this and I'm able to reproduce on a RHEL 6.3 kernel. What I see boils down to the umount failing with -EBUSY because the reference count on vfsmount->mnt_count is one larger than expected in the umount path (3 rather than 2).

Without knowing too much about the ecryptfs driver, I went through and tried to see where we're taking/releasing these references and I noticed that we do two nested path_lookup()'s of the same file path in the ecryptfs_get_sb() path. The first right in ecryptfs_get_sb(), the second is a kern_path() in ecryptfs_read_super(). I presume this reference is taken and held for a good reason, but thought it strange to reference twice. If I release the ecryptfs_read_super() reference before returning, the umount problem doesn't occur.

I also took a look at an upstream kernel (where the problem doesn't occur), and see that the ecryptfs_read_super() functionality is essentially folded up into ecryptfs_mount(). That seems to support this as the source of the issue, but I reiterate that I don't have enough context on the driver to specifically understand/audit the expected reference counting semantics.
Comment 3 Eric Sandeen 2012-02-06 21:33:24 UTC 
Ok, over to you Brian.  :)  Your fix looks good, and while we aren't investing a lot in ecryptfs right now, we should probably at least fix our (my ...) regressions.

QA: Very easy reproducer on this one...

Thanks!

-Eric
Comment 4 RHEL Program Management 2012-02-06 21:39:12 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 6 Aristeu Rozanski 2012-02-15 19:57:33 UTC 
Patch(es) available on kernel-2.6.32-231.el6
Comment 11 errata-xmlrpc 2012-06-20 08:09:52 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2012-0862.html
Note You need to log in before you can comment on or make changes to this bug.