On Sun, Jun 3, 2018 at 3:26 AM, Klemens Nanni <k...@openbsd.org> wrote:
> Snap from 31.05.2018 with > > OpenBSD 6.3-current (GENERIC.MP) #0: Sat Jun 2 16:21:22 CEST 2018 > k...@x250.my.domain:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > acquiring duplicate lock of same type: "&mp->mnt_lock" > 1st vfslock @ /usr/src/sys/kern/vfs_subr.c:191 > 2nd vfslock @ /usr/src/sys/kern/vfs_subr.c:191 > Starting stack trace... > witness_checkorder(9,ffffffff81ab15c8,bf,ffff800000d00040,21) at > witness_checkorder+0x63d > _rw_enter(0,1,0,ffff800000d00000) at _rw_enter+0x56 > vfs_stall(1,ffff800000025400) at vfs_stall+0xab > [Also reported by bluhm@ and others] Is vfs_stall() the only place that locks (busies) multiple mounts? If it's the only place _and_ it hotlds no other locks when doing that then I think it actually is safe, because it would be equivalent to multiple threads each holding only a single mount lock and nothing else. Even if we agree that evaluation is correct, I don't think we want to mark mnt_lock as DUPOK for all purposes, but rather just pass LOP_DUPOK through for the calls from vfs_stall(). Philip Guenther
