Ubuntu
linux package

chroot+overlayfs seems to cause umount mis-behavior

Bug #1098378 reported by Serge Hallyn
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
High
Unassigned
Raring
Won't Fix
High
Unassigned

Bug Description

If you mount an overlayfs under a loopback fs, chroot into it and mount something, then the loopback device cannot be released. In quantal it could, but in raring it hangs. I will attach a script which triggers the bug (in raring).

It doesn't happen with aufs; it doesn't happen if you mount without chrooting or pivot-rooting; it doesn't happen if you chroot but don't do any mounting.

See original description
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :
description: updated
Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Marking confirmed as it's been seen by >1 people (stgraber and myself).

Changed in linux (Ubuntu):
status: New → Confirmed
importance: Undecided → High
Joseph Salisbury (jsalisbury)
tags: added: needs-bisect raring
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Can you see if this also happens with the latest mainline kernel, which can be downloaded from:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-rc3-raring/

tags: added: kernel-da-key
Revision history for this message
Stéphane Graber (stgraber) wrote :

Thanks for the automated comment ;) Overlayfs isn't a mainline feature so we obviously can't test that kernel.

Brad Figg (brad-figg)
tags: added: kernel-stable-key
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Does this issue still exist in Raring with the latest updates? Also, can you see if the bug also exists in Saucy?

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

both raring and saucy still do this.

Scott Moser (smoser)
tags: added: overlayfs
Revision history for this message
Andy Whitcroft (apw) wrote :

@serge -- after a lot of debugging I think we have this one nailed. Could you test out the kernels for raring and saucy below and confirm the resolve the umount issue:

    http://people.canonical.com/~apw/lp1098378-raring/
    http://people.canonical.com/~apw/lp1098378-saucy/

Please report your testing here.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Thanks Andy, that fixes it! (Tested the raring kernel).

I haven't explicitly tested in quantal, but suspect it was new in raring.

Revision history for this message
Serge Hallyn (serge-hallyn) wrote :

Indeed, quantal is not affected.

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 3.9.0-5.12

---------------
linux (3.9.0-5.12) saucy; urgency=low

  [ Andy Whitcroft ]

  * Revert "HAVE_CPLUS_DEMANGLE=n"
  * SAUCE: intel_pstate -- toggle default to disable
    - LP: #1188647
  * SAUCE: ubuntu: overlayfs -- ovl_path_open should not take path
    reference
    - LP: #1098378
 -- Andy Whitcroft <email address hidden> Wed, 12 Jun 2013 13:28:56 +0100

Changed in linux (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Ed Hutchins (eh-s) wrote :

We're seeing something very similar to this bug in 12.04LTS (kernel 3.2.0-49-generic) running LXC containers on overlayfs mounts. In our case a front-end script we're using to run tests in isolation successfully umounts the overlayfs after the contained test completes, but attempting to rmdir the mountpoint fails. There are no processes left keeping the mount busy, and the umount completes without complaint. Interestingly after a few seconds (5 - 20) the mount is no longer busy, and sometimes everything works without incident. I've looked at the overlayfs source in the kernel and it seems to have the same issue as above; any chance this can patch can be back-ported?

Revision history for this message
Joseph Salisbury (jsalisbury) wrote : Closing unsupported series nomination.

This bug was nominated against a series that is no longer supported, ie raring. The bug task representing the raring nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu Raring):
status: Confirmed → Won't Fix
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.