Bug #2276
closed
umount mfs crash - Fatal trap 12
Added by thomas.nikolajsen almost 13 years ago.
Updated almost 13 years ago.
Description
Using fresh master (January 17th 2012),
umount of mfs mount crashes system.
This happens every time; core dump avail on request.
-thomas
-
Fatal trap 12: page fault while in kernel mode
..
> trace
vfs_start()
sys_mount()
On Tue, Jan 17, 2012 at 10:30:04AM -0800, Thomas Nikolajsen via Redmine wrote:
Issue #2276 has been reported by Thomas Nikolajsen.
----------------------------------------
Bug #2276: umount mfs crash - Fatal trap 12
http://bugs.dragonflybsd.org/issues/2276
Using fresh master (January 17th 2012),
umount of mfs mount crashes system.
This happens every time; core dump avail on request.
I cannot reproduce this. Can you please make the core available and write
the exact sequence of commands you use to make your system crash ?
--
Francois Tigeot
Core dump uploaded to leaf: ~thomas/crash/38
How to reproduce (results in immediate crash here every time):
on i386 (didn't try x86_64 yet)
- mount mfs file system, and umount i again
mkdir /boot/tmp2
mount -t mfs -o -s=655360 swap /boot/tmp2
umount /boot/tmp2
Core dump for x86_64 uploaded to leaf: ~thomas/crash/1
Same procedure to reproduce;
here kernel crashes with trap 9.
Here's the problem:
MFS's mfs_start() routine is not like other filesystems; the userland mount_mfs enters the mfs_start routine and processes copyin/copyout requests to transfer data into its userland mmap-ed region. When it returns after either being signalled or the filesystem being unmounted, the mount structure is not valid.
Unfortunately, sys_unmount() already kfree-d the mount structure; both the accounting init and MPUNLOCK in vfs_vfsops.c:vfs_start() are not safe; they are accessing the mountpoint after it is freed.
This should be fixed by commit f39f7550bfabac2d1290b91a0e5c6c37d276bca7.
- Description updated (diff)
- Status changed from New to Closed
Also available in: Atom
PDF