https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=298201
Bug ID: 298201
Summary: unionfs: panic "lockmgr_xlock_hard: recursing on non
recursive lockmgr"
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: kern
Assignee: [email protected]
Reporter: [email protected]
Created attachment 274425
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=274425&action=edit
dirty patch
Tested on the latest current (4th September).
Mounting a directory with `mount -t unionfs -o below` on a mount point located
on tmpfs, then looking that mount point up, panics the kernel.
`unionfs_root()` calls `_vn_lock()` on a vnode whose lock is already held
exclusively by the same thread further up the lookup path
(`namei()` -> `vfs_lookup()` -> `vfs_lookup_cross_mount()` ->
`unionfs_root()`),
and the unionfs vnode lock is not marked recursive, so `lockmgr_xlock_hard()`
panics.
Reproducible with this script:
----
#!/bin/sh
set -e
kldload -n unionfs tmpfs
D=/var/tmp/unionfs-below-panic
mkdir -p $D/lower $D/tmpfs
mount -t tmpfs tmpfs $D/tmpfs # the mount point must live on tmpfs
mkdir $D/tmpfs/upper
mount -t unionfs -o below $D/lower $D/tmpfs/upper
ls $D/tmpfs/upper # <- panics here
echo "no panic"
----
A matrix:
| lower layer | mount point | `-o below` | result |
|-------------|-------------|------------|----------|
| tmpfs | tmpfs | yes | panic |
| UFS | tmpfs | yes | panic |
| tmpfs | UFS | yes | no panic |
| UFS | UFS | yes | no panic |
| tmpfs | tmpfs | no | no panic |
Without `-o below` the same sequence completes normally, so the panic is
specific to `below` mode, where the mount point's own directory is the upper
layer.
The panic message:
panic: lockmgr_xlock_hard: recursing on non recursive lockmgr
0xfffff800164f73e0 @ /usr/src/sys/fs/unionfs/union_vnops.c:2257
cpuid = 0
time = 1788596398
KDB: stack backtrace:
#0 0xffffffff80ace605 at kdb_backtrace+0x75
#1 0xffffffff80a80429 at vpanic+0x149
#2 0xffffffff80a802d3 at panic+0x43
#3 0xffffffff80a564a7 at lockmgr_xlock_hard+0xb7
#4 0xffffffff82a45e5f at unionfs_lock+0x16f
#5 0xffffffff80b8bd51 at _vn_lock+0x51
#6 0xffffffff82a41b83 at unionfs_root+0x43
#7 0xffffffff80b65cf2 at vfs_lookup_cross_mount+0xe2
#8 0xffffffff80b65047 at vfs_lookup+0x7a7
#9 0xffffffff80b63f6d at namei+0x28d
#10 0xffffffff80b83c61 at kern_statat+0x121
#11 0xffffffff80b83b02 at sys_fstatat+0x32
#12 0xffffffff80edbf89 at amd64_syscall+0x129
#13 0xffffffff80ead79b at fast_syscall_common+0xf8
A very quick/dirty patch attached
--
You are receiving this mail because:
You are the assignee for the bug.
