Bug 205483

Summary: unionfs panics when used with nullfs
Product: Base System Reporter: Yuri Victorovich <yuri>
Component: kernAssignee: freebsd-fs (Nobody) <fs>
Status: New ---    
Severity: Affects Only Me CC: bugmeister, c.kworr
Priority: ---    
Version: 10.2-STABLE   
Hardware: amd64   
OS: Any   
Attachments:
Description Flags
kernel messages none

Description Yuri Victorovich freebsd_committer freebsd_triage 2015-12-21 09:39:09 UTC 
Created attachment 164448 [details]
kernel messages

When ports are mounted through unionfs+nullfs:
> /usr/ports.patches     /usr/ports     nullfs   ro           0 0
> /usr/ports.subversion  /usr/ports     unionfs  rw,noatime   0 0

disk activity in /usr/ports causes panics. See messages attached.

(I am not sure that nullfs is required to reproduce this, I just assumed it is.)

10.2-STABLE r292527
Comment 1 c.kworr 2015-12-21 17:44:40 UTC 
Same to me. I'm using unionfs/nullfs to secure wordpress installations. Fstab sample:

/usr/local/www/wordpress /home/price-/www/site1/articles nullfs ro,late 0 0
/home/price-/www/site1.local /home/price-/www/site1/articles unionfs ro,late 0 0
/home/price-/www/site1/wp-content/uploads /home/price-/www/site1/articles/wp-content/uploads nullfs rw,late 0 0

Recently I added fourth site and directory with uploads just failed to become writable even though all the mounts were successful.

When I tried to move back to previous configuration utilizing only unionfs via `below` mounting:

/usr/local/www/wordpress /home/price-/www/site1/articles below ro,late,below 0 0
/home/price-/www/site1.local /home/price-/www/site1/articles unionfs ro,late 0 0
/home/price-/www/site1.local/wp-content/uploads /home/price-/www/site1/articles/wp-content/uploads unionfs rw,late 0 0

It just died with:

panic: __lockmgr_args:downgrade a recursed lockmgr zfs @ /usr/src/sys/modules/unionfs/../../fs/unionfs/union_vnops.c:1936

cpuid = 6
KDB: stack backtrace:
#0 0xffffffff803cf770 at kdb_backtrace+0x60
#1 0xffffffff80396086 at vpanic+0x126
#2 0xffffffff80395f53 at panic+0x43
#3 0xffffffff80374a1d at __lockmgr_args+0xe6d
#4 0xffffffff80425d1c at vop_stdlock+0x3c
#5 0xffffffff80627c0b at VOP_LOCK1_APV+0xab
#6 0xffffffff811a2ced at unionfs_lock+0x3cd
#7 0xffffffff80627c0b at VOP_LOCK1_APV+0xab
#8 0xffffffff811a2c03 at unionfs_lock+0x2e3
#9 0xffffffff80627c0b at VOP_LOCK1_APV+0xab
#10 0xffffffff80444003 at _vn_lock+0x43
#11 0xffffffff811a2508 at unionfs_readdir+0x148
#12 0xffffffff806277c7 at VOP_READDIR_APV+0xa7
#13 0xffffffff8044159c at kern_getdirentries+0x21c
#14 0xffffffff80441358 at sys_getdirentries+0x28
#15 0xffffffff805eeaf7 at amd64_syscall+0x357
#16 0xffffffff805d3a1b at Xfast_syscall+0xfb

I know this is not exactly the same situation as the reporters but we do share a common situation where (I suppose this is unionfs) it fails: joining more than two filesystems by the same mountpoint.
Comment 2 Yuri Victorovich freebsd_committer freebsd_triage 2015-12-21 18:12:00 UTC 
Did you try doing the same with only unionfs instead?

As I learned now, man page mount_unionfs says unionfs is broken. I just don't know to what extent.
Comment 3 c.kworr 2015-12-21 18:56:53 UTC 
AFAIR it was sometimes unstable under load so I was searching for any other to ditch unionfs.

I'm still thinking about trying fusefs-unionfs though...
Comment 4 Yuri Victorovich freebsd_committer freebsd_triage 2015-12-21 19:06:17 UTC 
fusefs-* is probably much slower.
Comment 5 Mark Linimon freebsd_committer freebsd_triage 2025-02-11 00:10:15 UTC 
^Triage: to submitter: is this still a problem on supported versions of FreeBSD?