Description of problem: Due to some foolishness on my part, I was attempting to bind mount a file onto /proc/self/cgroup, instead of /proc/THE-ACTUAL-PID/cgroup. I noticed that when I do this, I get a stale, non-removeable entry in the kernel mount table. # cp /proc/self/cgroup /root/cgroup # mount --bind /root/cgroup /proc/self/cgroup # grep proc /proc/mounts proc /proc proc rw,relatime 0 0 systemd-1 /proc/sys/fs/binfmt_misc autofs rw,relatime,fd=33,pgrp=1,timeout=300,minproto=5,maxproto=5,direct 0 0 binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,relatime 0 0 sunrpc /proc/fs/nfsd nfsd rw,relatime 0 0 /dev/mapper/vg_t500wlan-lv_root /proc/26770/cgroup ext4 rw,seclabel,relatime,data=ordered 0 0 # umount -f /proc/26770/cgroup umount: /proc/26770/cgroup: not found In fact if I use /proc/1234/cgroup, i'll hit the same problem when process 1234 exits. So the kernel doesn't appear to cleanup bind mounts under any /proc/NNNNN/ location when the process NNNN exits. Version-Release number of selected component (if applicable): kernel-3.9.9-302.fc19.x86_64 How reproducible: Always Steps to Reproduce: 1. Bind mount a file onto /proc/NNNN/YYYY, where NNN is any process ID, or 'self' 2. Let the process NNN exit 3. Look for the mount bind Actual results: The bind mount still exists & cannot be removed, since /proc/NNN no longer exists Expected results: Any mounts under /proc/NNNN are purged when process NNN exits. Additional info:
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs. Fedora 19 has now been rebased to 3.11.1-200.fc19. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug has been in a needinfo state for more than 1 month and is being closed with insufficient data due to inactivity. If this is still an issue with Fedora 19, please feel free to reopen the bug and provide the additional information requested.