Bug 766554

Summary:	ecryptfs keeps directory busy even after umount
Product:	Red Hat Enterprise Linux 6	Reporter:	Michal Hlavinka <mhlavink>
Component:	kernel	Assignee:	Brian Foster <bfoster>
Status:	CLOSED ERRATA	QA Contact:	Radek Pazdera <rpazdera>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.0	CC:	bfoster, jtluka, kzhang, mzywusko, rpazdera
Target Milestone:	rc	Keywords:	Regression
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	kernel-2.6.32-231.el6	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-06-20 08:09:52 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:

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