Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 19 May 2013 23:47:25 +0000
From:      Antoine Brodin <antoine@FreeBSD.org>
To:        freebsd-fs@freebsd.org
Cc:        Konstantin Belousov <kib@freebsd.org>
Subject:   Re: Nullfs - Panic when umounting and lower fs has been removed
Message-ID:  <CAALwa8=Ng=2LP1ARiVS1-C1fGpJqz_3bW32PwbP9EnGJ4cDyCg@mail.gmail.com>
In-Reply-To: <CAALwa8nrUbErf9hghdFBOD0Y6yGWD5wYPqQ1Ef4qx_pp7E3Z%2BA@mail.gmail.com>
References:  <CAALwa8nrUbErf9hghdFBOD0Y6yGWD5wYPqQ1Ef4qx_pp7E3Z%2BA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 19, 2013 at 8:41 PM, Antoine Brodin <antoine@freebsd.org> wrote:
> Hi there,
>
> I encountered a panic on head today with nullfs using poudriere.
>
> It is quite easy to reproduce,  the script is probably doing something
> wrong but panicking is not nice
>
> %%%
> mkdir /tmp/.new_packages /mnt/new_packages
> mount -t nullfs /tmp/.new_packages /mnt/new_packages
> dd if=/dev/zero of=/mnt/new_packages/bar count=20000
> mv /tmp/.new_packages/bar /tmp/
> rm -rf /tmp/.new_packages
> umount -f /mnt/new_packages
> %%%
>
> The panic:
>
> userret: returning with the following locks held:
> exclusive lockmgr ufs (ufs) r = 0 (0xfffffe0010a77548) locked @
> /usr/src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c:615
> panic: witness_warn
> cpuid = 0
> KDB: enter: panic
>
> db:1:lockinfo> show locks
> exclusive lockmgr ufs (ufs) r = 0 (0xfffffe0010a77548) locked @
> /usr/src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c:615
>
> db:1:locks>  show alllocks
> Process 1032 (umount) thread 0xfffffe0010623920 (100116)
> exclusive lockmgr ufs (ufs) r = 0 (0xfffffe0010a77548) locked @
> /usr/src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c:615
>
> db:1:alllocks>  show lockedvnods
> Locked vnodes
> 0xfffffe0010a774e0: tag ufs, type VDIR
>     usecount 0, writecount 0, refcount 0 mountedhere 0
>     flags (VI_FREE)
>     v_object 0xfffffe0010af0960 ref 0 pages 0
>     #0 0xffffffff8088cd59 at __lockmgr_args+0x979
> #1 0xffffffff80af4df2 at ffs_lock+0x92
> #2 0xffffffff80ce96f9 at VOP_LOCK1_APV+0xf9
> #3 0xffffffff81a5f8df at null_lock+0xdf
> #4 0xffffffff80ce96f9 at VOP_LOCK1_APV+0xf9
> #5 0xffffffff8095a836 at _vn_lock+0xc6
> #6 0xffffffff8094b681 at vflush+0x3a1
> #7 0xffffffff81a5eace at nullfs_unmount+0x2e
> #8 0xffffffff809436cb at dounmount+0x39b
> #9 0xffffffff8094330b at sys_unmount+0x37b
> #10 0xffffffff80c41322 at amd64_syscall+0x282
> #11 0xffffffff80c2981b at Xfast_syscall+0xfb
>
> db:0:kdb.enter.panic>  bt
> Tracing pid 1032 tid 100116 td 0xfffffe0010623920
> kdb_enter() at kdb_enter+0x3e/frame 0xffffff8122567940
> vpanic() at vpanic+0x146/frame 0xffffff8122567980
> kassert_panic() at kassert_panic+0x136/frame 0xffffff81225679f0
> witness_warn() at witness_warn+0x4e4/frame 0xffffff8122567ab0
> userret() at userret+0x89/frame 0xffffff8122567ae0
> amd64_syscall() at amd64_syscall+0x397/frame 0xffffff8122567bf0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xffffff8122567bf0
> --- syscall (0, FreeBSD ELF64, nosys), rip = 0x80087abcc, rsp =
> 0x7fffffffd398, rbp = 0x800c0a9d0 ---

Reverting r250505 fixes this issue.

Cheers,

Antoine



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAALwa8=Ng=2LP1ARiVS1-C1fGpJqz_3bW32PwbP9EnGJ4cDyCg>