Bug #2276

umount mfs crash - Fatal trap 12

Added by thomas.nikolajsen over 2 years ago. Updated about 2 years ago.

Status:ClosedStart date:01/17/2012
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

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()


Related issues

Related to Bug #2286: 3.0 release catchall ticket Closed 01/22/2012

History

#1 Updated by ftigeot over 2 years ago

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

#2 Updated by thomas.nikolajsen over 2 years ago

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

#3 Updated by thomas.nikolajsen over 2 years ago

Core dump for x86_64 uploaded to leaf: ~thomas/crash/1

Same procedure to reproduce;
here kernel crashes with trap 9.

#4 Updated by me1 about 2 years ago

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(mp) in vfs_vfsops.c:vfs_start() are not safe; they are accessing the mountpoint after it is freed.

#5 Updated by me1 about 2 years ago

This should be fixed by commit f39f7550bfabac2d1290b91a0e5c6c37d276bca7.

#6 Updated by vsrinivas about 2 years ago

  • Description updated (diff)
  • Status changed from New to Closed

Also available in: Atom PDF