Created attachment 483433 [details] mount script Description of problem: Doing multiple umounts in parallel of a bunch of ext4 file systems causes umount to return "not mounted" for some file systems, even if /etc/mtab is a symlink to /proc/mounts. Also, running the mount script a few times causes the kernel to crash. One crash dump attached. Version-Release number of selected component (if applicable): kernel-2.6.38-0.rc8.git0.2.fc14.x86_64 How reproducible: Always Steps to Reproduce: 1. boot with loop.max_loop=256 2. sudo ./testext4.py 3. cat /proc/mounts | grep /dev/loop | cut -d " " -f 1 | perl -ne 's/^/sudo umount /; s/$/&/; print' | sh -x Actual results: A few of the umounts fail with "not mounted". If you check /proc/mounts, the file systems are in fact mounted and another attempt to umount them succeeds. Also, running ./testext4.py a few times with umounts in between causes the kernel to crash. One screenshot attached. I am running on a machine with 24 cores.
Created attachment 483435 [details] screenshot
Created attachment 483436 [details] screenshot 1
Created attachment 483437 [details] screenshot 2
Created attachment 483438 [details] screenshot 3
Created attachment 483442 [details] kernel crash
COmment #5 does indeed look like an unmount race, calling completion on something which has gone away. Might be worth testing with a completely different filesystem (xfs, perhaps) to see whether some of this might be more of a vfs issue.
Same umount race with XFS.
This probably needs to be reported upstream?
(In reply to comment #8) > This probably needs to be reported upstream? Actually yes, that would be good. Upstream has more bandwidth for bugs than I do alone. :) Thanks, -Eric
Reported here: https://bugzilla.kernel.org/show_bug.cgi?id=32312
According to Jan Kara, this bug should have been fixed by commit 0aeea18964173715a1037034ef6838198f319319 by lczerner, which went into 2.6.39-rc1.
(In reply to comment #11) > According to Jan Kara, this bug should have been fixed by commit > 0aeea18964173715a1037034ef6838198f319319 by lczerner, which went > into 2.6.39-rc1. That patch actually went in 2.6.38 just before release.
I have retested with kernel-2.6.38.4-20.fc15.x86_64, and the bug is still there. So if 0aeea18964173715a1037034ef6838198f319319 is in 2.6.38, it doesn't fix this bug.
(In reply to comment #13) > I have retested with kernel-2.6.38.4-20.fc15.x86_64, and the bug is still > there. Did the crash appear on the kernel-2.6.38.4-20.fc15.x86_64 as well ? Or just the "not mounted" error ?
Hello I did a few tests and ut seems the crash is fixed in kernel-2.6.38.4-20.fc15.x86_64, but the "not mounted" error still appears. Regards Albert
Hello I did a few tests and it seems the crash is fixed in kernel-2.6.38.4-20.fc15.x86_64, but the "not mounted" error still appears. Regards Albert
Good, that's what I though. So Jan was right the crash has been fixed by that commit. The "not mounted" (EINVAL) error is however completely different problem and should have it's own bz entry. So if you do not mind I will close this one and you can open the new bz for that "not mounted" error (please cc me). Thanks Albert! -Lukas