svn commit: r301929 - head/sys/kern

[Konstantin Belousov]

On Tue, Jun 21, 2016 at 09:49:24PM +0300, Andriy Gapon wrote:
> On 15/06/2016 18:56, Konstantin Belousov wrote:
> > Author: kib
> > Date: Wed Jun 15 15:56:03 2016
> > New Revision: 301929
> > URL: https://svnweb.freebsd.org/changeset/base/301929
> > 
> > Log:
> >   Do not assume that we own the use reference on the covered vnode until
> >   we set MNTK_UNMOUNT flag on the mp.  Otherwise parallel unmount which
> >   wins race with us could dereference the covered vnode, and we are
> >   left with the locked freed memory.
> >   
> >   Reported and tested by:	pho
> >   Sponsored by:	The FreeBSD Foundation
> >   Approved by:	re (gjb)
> >   MFC after:	1 week
> 
> 
> Kostik,
> 
> does this change fix (or is likely to fix) the following panic?
Yes, this is exactly the problem that was reported,
Peter made sure that he is able to reproduce the issue at will,
and that the patch fixed it.

> Thanks!
> 
> VNASSERT failed
> 0xfffff8000c926588: tag none, type VBAD
>     usecount 0, writecount 0, refcount 0 mountedhere 0
> VNASSERT failed
> 0xfffff8000e95f000: tag none, type VBAD
>     usecount 0, writecount 0, refcount 0 mountedhere 0
>     flags ()
>     lock type zfs: EXCL by thread 0xfffff80020921a00 (pid 2017, zfs, tid
> 100794)
> panic: No vop_unlock(0xfffff8000e95f000, 0xfffffe004df8a980)
> cpuid = 2
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfffffe004df8a820
> vpanic() at vpanic+0x182/frame 0xfffffe004df8a8a0
> kassert_panic() at kassert_panic+0x126/frame 0xfffffe004df8a910
> VOP_UNLOCK_APV() at VOP_UNLOCK_APV+0x94/frame 0xfffffe004df8a940
> dounmount() at dounmount+0x138/frame 0xfffffe004df8a9c0
> sys_unmount() at sys_unmount+0x35d/frame 0xfffffe004df8aae0
> amd64_syscall() at amd64_syscall+0x2db/frame 0xfffffe004df8abf0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfffffe004df8abf0
> --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x8012f4e4a, rsp =
> 0x7fffffffc298, rbp = 0x7fffffffc300 ---
> KDB: enter: panic
> [ thread pid 2017 tid 100794 ]
> Stopped at      kdb_enter+0x3b: movq    $0,kdb_why
> 
> P.S.  Not sure why two VNASSERTs are reported here, but this is copied
> verbatim from a console.
Most likely you got two CPUs checking the same assert, but only one was
able to enter the panic state. Look at the backtraces of running threads
on other processors.

> 
> > Modified:
> >   head/sys/kern/vfs_mount.c
> 
> 
> -- 
> Andriy Gapon